Roles for incident and change request

Yaseen2
Mega Expert

Dear All,

I have a question, what are the roles that should be added to user in order to work on incident and change request, noting that I need these users to view their own incidents and changes only, currently we have many support engineers i provided them with "ITIL" role but all of them are able to view and modify all incidents and change requests even they are not assigned to them.

Many thanks.

1 ACCEPTED SOLUTION

Stijn Verhulst3
Kilo Guru

Hi Yaseen,

I understand your mindset, though ServiceNow has provided the itil role on purpose, making therefore all incidents, problems and changes visible to anyone who has this role assigned:

  • It allows cooperation between multiple teams within a organization seamlessly who have to work on the same incident / problem / change or at least need to be able to consult it. For example, what if a support engineer is working on an incident which could be related to another one, assigned to another team and possibly not being visible? Then the relationship could not be made and you'll start getting duplicate incidents for example, bad end-to-end resolution tracking and possibly bad process maintenance on the longer term.

  • If it's about protecting sensitive information stored within those incidents / problems / changes which cannot be shared with everyone, those can still be restricted via ACLs and, if needed, in combination with particular roles.

So I'd think wisely whether you really want to alter this baseline behavior as it can break seamless co-operation between multiple teams in the organization.

View solution in original post

2 REPLIES 2

Ajaykumar1
Tera Guru

Hi Yassen,

Refer the following community thread.

How to filter incidents based on user groups and location?

Regards,
Ajay

Stijn Verhulst3
Kilo Guru

Hi Yaseen,

I understand your mindset, though ServiceNow has provided the itil role on purpose, making therefore all incidents, problems and changes visible to anyone who has this role assigned:

  • It allows cooperation between multiple teams within a organization seamlessly who have to work on the same incident / problem / change or at least need to be able to consult it. For example, what if a support engineer is working on an incident which could be related to another one, assigned to another team and possibly not being visible? Then the relationship could not be made and you'll start getting duplicate incidents for example, bad end-to-end resolution tracking and possibly bad process maintenance on the longer term.

  • If it's about protecting sensitive information stored within those incidents / problems / changes which cannot be shared with everyone, those can still be restricted via ACLs and, if needed, in combination with particular roles.

So I'd think wisely whether you really want to alter this baseline behavior as it can break seamless co-operation between multiple teams in the organization.