MSP domain separation ticket management by customers

[robbika]

Here's a question.

In a domain separated environment, we have the following domain structure:

TOP

        - Us

        - Customers

                  - Customer 1

                  - Customer 2

Us is well us the MSP company, Customers is the domain where customer domains will reside, and Customer 1 and Customer 2 are customer domains.

There is a contains relationship between 'Us' and 'Customers' so that Us can see all the data in Customers, but the customers can only see their own data.

Here is lies a problem. We have resolver groups that are shared across all domains. That's fine we put those groups in 'global' domain. The users though are in their respective domains. If the resolvers work for Us then they go in Us. If they work for Customer 1 then they are in Customer 1.

Fine so far. The tricky thing is that when for example a change manager in Customer 1 wants to assign a ticket to a resolver in 'Us'. They can assign to the group because it is in 'global' but not to a particular user because they can't see poeople in 'Us'.

In general, we usually say that you can assign to a group but not a user. The users in that group should see the ticket and then assign to themselves. But what if the customer really wants to assign a ticket to someone they know has to resolve the ticket?

We've not been able to come up with a way to do that by reorganising the domain structure or contains or visibility links or anything else.

Anyone got any ideas?

[robbika]

That is genius.

I will go one further.

What I've learnt in ServiceNow is that a large class of solutions involve the following:

  - add a field on a table

  - add a business rule

So how about:

  - add a field to the user table called 'Parallel User' which is a reference to the User table and is the actual user you want to appear on the Assigned To field

  - add a business rule, that checks the Assigned To user and if it has a set Parallel User field, then the Parallel User is substituted

I can actually see this being used in a lot of situations. The biz rule can be on the task table so it can apply to all kinds of tasks.

Do you see any issues with this one?

(I'd probably change the name but Parallel User was the best I could come up with right now.)

[williamsun]

This would prove to be too much work as you would have to change how everything works for the customers' assigned_to field.

I think if you use the same assigned_to and just have the rule automatically change it to the correct solver on a after update when assigned to changes to one of these "dummy users" would do the trick.

[robbika]

I don't think the problem is the assigned_to field.

A rule:

Table: task

Condition: current.assigned_to.u_parallel_user && current.assigned_to.changes()

Script:

current.assigned_to = current.assigned_to.u_parallel_user;

Can be specialised to work on only some tables, or for some groups with a special flag and so on.

Another thing is maybe the dummy user is in the global domain so it only has to be added once instead of for each domain that wants to use it.

There would need to be some housekeeping. When the user is made inactive then the dummy user should also be inactive. If the user is removed from a tagged group, then so should the dummy user, and vice versa.

I can see something like this working.

[BobbyNow · Accepted solution]

Robert,

The best practice in general, domain or not, is that only assignment_group is set by a 3rd party, and a fulfiller sets assigned_to to show acceptance of the task. In some cases a queue manager assigns resources they are responsible for as well.

Assuming this will not work, and you must allow 3rd parties in a child domain to set assigned_to for parent fulfillers, a possible solution could be to make the user table global, and then secure it dynamically with a before query.

You would need to make sure your code logic is not resource intensive, and do some performance testing.

prototype example:

1. Set the "global_visibility=true" attribute on the "sys_user" table "collection" record in the dictionary.

  This will make the user table GLOBAL meaning all user records are potentially available to everyone until the ACLs are applied

2. Create a before query business rule that limits users to user records in their own domain plus ones you create a special attribute for.

  Condition this rule so it does not run at all for MSP users

[robbika]

Thanks Bobby. That is very useful.

It still amazes me that there are 10 ways to do something in ServiceNow but usually there is only one simple way but it is not always easy to find.

So far we have gently insisted that customers use the assignment group approach. The tricky thing is that for some processes, like Change Management, where there are very few resolvers involved and often the requestor knows exactly who the request should go to, then assigning to a group but not a person seems like a waste of time for them. "I already know who this should go to!".

But if they still insist, because they are paying the bills afterall, then we will try your method.