Howdy!
I'm facing a problem relatively stupid, but pretty annoying.
We have just introduced a new organization (OrgB for short) where we serve the 1st level support and the organization is providing the 2nd level.
Because many of the services are shared, I have used the services already created for my organization (OrgA for short) in the customer contract for OrgB; obviously because the OrgB 2nd level is specific for that organization, all the agents of OrgB have configured the allowed organization only for OrgB (so they cannot see OrgA UserRequests).
Now we are facing the problem that because some services are provided by OrgA, the agents of OrgB are not allowed to see them and for this reason cannot close UserRequests (in the form the service is not populated).
Is anyone having this "issue"? How did you managed it?
BTW, I know that duplicating the service catalog for the OrgB should work, but I wanted to avoid it because it would generate too much work in case of a change of a service in our service catalog (we are trying to have a single service catalog from where take all the managed services).
BR,
Giorgio
Last edit: Giorgio Maggiolo 2022-07-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Giorgio,
There were some discussion already about segmenting the data in the console. It's not an easy game. Search in this forum...
Combodo offers to its customers an extension called "Department silos" which allow an IT and an RH department to serve the same population and be limited to their own tickets, but this is not a 1st level and second level vision at all and their services are not shared.
Another approach is to use the extension "Business Partner Portal" which is designed for an external company providing 2nd level support for some dedicated services. With that extension, they don't use the console but a dedicated portal, in which they only see ticket assigned to their team. Up to the agent to dispatch the Ticket to that third party team, when ever needed.
There are probably many other ways, which could be invented...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Vincent,
it's ok for me that the 2nd level support sees all the tickets (I have used the Allowed Organizations on their users so that they can see only the tickets of the orgs that are using).
The problem is that doing so, if a service is "provided" by an organization that is not allowed for them, they cannot see it.
So I was wandering whether was necessary the use of the "Provider" attribute inside the service class (that would be an easy way to resolve my specific case, but i don't know the implications of that).
BR,
Giorgio
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Howdy!
I'm facing a problem relatively stupid, but pretty annoying.
We have just introduced a new organization (OrgB for short) where we serve the 1st level support and the organization is providing the 2nd level.
Because many of the services are shared, I have used the services already created for my organization (OrgA for short) in the customer contract for OrgB; obviously because the OrgB 2nd level is specific for that organization, all the agents of OrgB have configured the allowed organization only for OrgB (so they cannot see OrgA UserRequests).
Now we are facing the problem that because some services are provided by OrgA, the agents of OrgB are not allowed to see them and for this reason cannot close UserRequests (in the form the service is not populated).
Is anyone having this "issue"? How did you managed it?
BTW, I know that duplicating the service catalog for the OrgB should work, but I wanted to avoid it because it would generate too much work in case of a change of a service in our service catalog (we are trying to have a single service catalog from where take all the managed services).
BR,
Giorgio
Last edit: Giorgio Maggiolo 2022-07-29
Hi Giorgio,
There were some discussion already about segmenting the data in the console. It's not an easy game. Search in this forum...
Combodo offers to its customers an extension called "Department silos" which allow an IT and an RH department to serve the same population and be limited to their own tickets, but this is not a 1st level and second level vision at all and their services are not shared.
Another approach is to use the extension "Business Partner Portal" which is designed for an external company providing 2nd level support for some dedicated services. With that extension, they don't use the console but a dedicated portal, in which they only see ticket assigned to their team. Up to the agent to dispatch the Ticket to that third party team, when ever needed.
There are probably many other ways, which could be invented...
Hi Vincent,
it's ok for me that the 2nd level support sees all the tickets (I have used the Allowed Organizations on their users so that they can see only the tickets of the orgs that are using).
The problem is that doing so, if a service is "provided" by an organization that is not allowed for them, they cannot see it.
So I was wandering whether was necessary the use of the "Provider" attribute inside the service class (that would be an easy way to resolve my specific case, but i don't know the implications of that).
BR,
Giorgio