SOW - Incident form layout examples
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi All,
We are in the process of setting up Service Operations Workspace (SOW). We are fairly early and we know what fields we need on the incident form for our teams to work but we want to shake up our standard layout. The initial assumption has been to just recreate the classicUI to minimize friction but I figure, we should look to the future of what will work best. The friction will happen with the changeover regardless so provided its a better way of working, I dont mind the extra friction and we will look for extra OCM/Training to help with it.
I am keen to know from those who have successfully implemented SOW, what was the key to success in your layout? My issue is that the classicUI had extra tabs to hide things like Major incident details (business impact, probable cause etc), Resolution details, related records (Parent incident, problem, caused by change etc) but SOW puts them all on one page (details tab). They are collapsable which may be enough.
My questions, Have you created any custom tabs to move some of this information to? if so what was moved and how do your fulfillers find it?
OR
Have you left Major Incident, Related records and resolution fields on the details tab in a way that works without frustrating your fulfillers (to much scrolling, not enough screen real estate etc)?
OR
Did you do something else that you can share?
I am keen for ideas that I can share with our designers and would love input from those who have had success in SOW.
Thanks
Peter
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Put them there in a logical way. You can't just create separate tabs, assuming it will work in the workspace, because then you will need to recreate the logic and pages behind it as well. And that will immediately start your usage of SOW with technical dept that will need to be maintained into eternity. No OOB updates will come automatically, because you have it on separate tabs (=custom ui builder development).
Make sure that they can no longer use the old forms, because they will, no matter how much training/OCM you are going to use.
Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago - last edited 3 weeks ago
Thanks Mark, I hear you, I think we'd still like to explore extra tabs, especially for Variable information thats added to incidents created from catalog items. I've noted your feedback and will discuss with our developer to ensure we have a process to handle it if we go down this path. I'm still keen to know if anyone has gone down the rout of adding extra tabs and what they used them for, and any impact they may have had.
I agree with turning off the old forms, once we are certain we have catered for all (or at least the vast majority) of use cases then we will switch the old ones off.