not without customisation.
This is not possible without Customizing.
How do customers create their tickets? If you are using SRM or DWP, you can separate this very cleanly by configuration.
Damn, why are you so fast? Give me a few more minutes
2 of 2 people found this helpful
If SRM or DWP is used for submittal, it is possible to limit user's choice of priority, even to the point of introducing blacklisting specific users, but if this needs to be dynamic, it would take a bit to set up additional form(s), populate data and it might require periodic management of that list; static restrictions are fairly simple -- one way of implementing static restrictions is via SRD's actions by using one of available fields in CTM:People (or adding one if nothing can be repurposed) to tag account as restricted and restricting priority menu on submittal form based on it.
On the other hand, priority on customer's side could be mentally and actually decoupled from priority on support's side -- in my experience, a lot of people (instinctively?) consider those as (separate views of) the same attribute (and often attach service level targets to it, as well, which then influences conditions of service level compliance), instead of using customer's priority from submittal form to inform support about that particular customer's priorities (which may or may not align with those of support) and priority from support application (e.g. Incident Management) to handle internal prioritization and ordering.
Thank you for your reply. We are using SRM.
Then you have everything you need. Offer your SRM customers something more abstract than impact/urgent (priority), e.g. number of affected users or individual cases, team, department, company.
Then you don't transfer the values 1:1 but as your support organization sees it or your contracts require it.