Submitting tickets on behalf of clients

[Ryan S]

Hi All,

I'm curious how folks are handling the different scenarios where an MSP is creating tickets for a client and being able to track the original requester. Speaking in a domain-separated environment. Apologies in advance if this is confusing as I'm still wrapping my head around parts of it.

Let's say MSP provides an application hosted in MSP environment, to client A. If the client is requesting something related to this service, a Service Request could be created under 'Client A' and the 'Requested For' can be a user in Client A's Company. What if the request is indirectly for the client? Maybe it's the MSP application team (tier 2) that needs to request a patch on the OS. It's still related to Client A but the 'Requested For' really wouldn't make sense as a client user. What company and requested_for are used in this (or other) scenarios?

Ok, let me pause there before I confuse things more. Hopefully starting a conversation...

[GlideFather]

Hi @Ryan S,

it's been like 5 years or so but we had a client with similar scenario.

It was Incident - Incident (eventually RITM-RITM) integration, depending on the vendors some where uni- and some bidirectional. And if there was a need for a third party it was creating an incident task(s) for them.

I don't remember exact details but if you want to discuss something in particular, we can do it. Also, it was not entirely the most recommendable implementation but I believe it was quite okay from the design perspective.

Let me know

[Ryan S]

Hi Kamil,

I think you're talking about e-bonding which isn't the scenario here. There's just the one (domain-separated) instance.

[Di Zhang]

Hi Ryan S,

I believe the handling of the 'Requested For' field depends on the scenario. Typically, this field is set so only the requester can view their own ticket. This approach doesn't cause conflicts. In fact, clients often require this visibility restriction even in domain-separated environments.

For your specific case (like the MSP team requesting an OS patch for Client A's system), consider these alternatives:

1. Use a dummy requester (e.g., "Client A - System Account")

2. Assign the application owner

3. Designate the client's primary contact
   This maintains the association with Client A while avoiding illogical user assignments.

[Kim Sullivan]

We have requested for/caller and company field on all our catalog items.  You could then create a service account user in your TOP domain to use for these situations.  Then on your form, use the service account and then change the Company to the client.