MSP domain separation ticket management by customers

robbika · ‎11-01-2014

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?

BobbyNow · ‎11-21-2014

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

View solution in original post

williamsun · ‎11-01-2014

The customer should really not decide who will work on their ticket. You have a contract with the customer to solve their tickets within conditions based on workload and availability of your staff that they are not privy to. What if they assign it to someone who just went on a vacation?

That being said, there is not "easy" solution to this. You could

Make your solvers global as well
Create another field with a Select box that populated the Name and Sys_id of the solvers that populated the real assigned_to (like a "who would you prefer to solve this ticket" field)
Give the privileged change_managers visibility into the domain where the solvers are and restrict everything else through roles
Depending on how many "solvers" you have, control it through UI Actions on the form that would assign the solver ("Assign to John Smith", "Assign to Beth Anglin", etc.)
Let them know that it's not usual, but if they had a preference, they should "call in" to your service desk to let them know of their preference and to please assign the solver accordingly.

robbika · ‎11-02-2014

Thank you for your suggestions.

I can see there is no easy answer to this one.

Probably putting the solvers to global would be the most transparent way although we would have to make sure that they their domain somehow always defaulted to 'Us' domain and not global when they logged in.

Another one could be to make a group per solver, so 'Customer 1 Change Resolver Fred Bloggs' and with only user Fred Bloggs in that group, and then maybe a rule to automatically assign those kind of groups to that user anyway.

But yes, I think assigning to groups would be the best way out of this, although the customer says they want to user the same procedure as they have always been using, which is to assign to a group and a user at the same time.

robbika · ‎11-02-2014

Another idea we had was to have a domain 'Resolvers' for those resolvers which has a contains relationship with 'Us' and 'Customers'. Or maybe 'Resolvers' can be a sub-domain of 'Us' but be contained by 'Customers'.

It's difficult to see what the implications of that would be though.

williamsun · ‎11-02-2014

NEw idea:

create dummy user records in each domain. You can then have a rule that when any record is assigned to dummy user 1, 2 or 3, reassign to real user x.

they can have same "name, just make sure the user-name is different (unique) and that your US users know how to tell the dummy records apart like "Solver Guy (Domain 3)" as the display name.