I'll check that John. Thanks a lot.
that looks promising
Although there are a few proposed workarounds for the issue, I think that none of them handles it 100%.
If a service request is created from an incident that was submitted through a service, the user sees two entries under My Stuff (one with the request ID from SB and another one with the request ID from SRM).
If a service request is not created when an incident is submitted through a service, the end user does not get notifications from SRM. This means one of three things:
- end user will not get any notifications for these requests if incident management notifications are disabled (which is bad);
- end user will get notifications from the incident if incident management notifications are enabled (which is not very good either because the end user is not even supposed to know what the backend ticket is - an incident, a work order, etc.);
- end user will get custom notifications from service broker if such are defined in the workflow (which might be the best of the three but it is still a bit bad and needs to be handled explicitly in every workflow).
And things become even worse if an incident is created via email or a call to service desk because in this case there is no ID from service broker (and end users will either get an ID from SRM or an incident ID, depending on configurations). This is really confusing for them. It will be much better if end users always get the same type of ID (and same notifications), no matter how they submitted their incident.
John Gallagher, do you know whether there are any improvements related to handling of request IDs planned for new versions of Digital Workplace Advanced, so that we do not have to come up with workarounds that are never good enough for end users?