CA Service Management

Hello SD Teams

I want to discuss my environment with the expert consultant here. Currently we have have sdm with NO Tenants Installed yet. Now we have implemented sdm 17.1 and want to enable Multi Tenants in our servicedesk. You can see below screenshot of employee home page where our end users create Incident, Request & Change Orders.

Currently when end user create 'CRM Incident', user also see categories of ERP, RMS, HELPDESK and CONTACT CENTER because IN form is using by all.

Now we are planning to create tenants new sdm like

1.CRM

2.ERP

3.HelpDesk

4.Contact Center

So the end user can see their own relevant data on form. Like if user create RMS incident, so only Only RMS data show on form and not other. so this can be do able by having tenants.

But we have almost 10,000 + endusers who create multple incidents like CRM and helpdesk both...some users create Contact center and ERP  Incident Both.

Now if the user is under CRM Tenant. How will the user can create ticket for other tenants also from employee role.???? as we have more than 10,000 endusers who has only Employee accesstype. and we cannot assign them any other role.

Please put your  suggestionss

Thanks

Hi Aamir,

From what you're describing, it sounds like multi-tenancy may not be the best way to implement what you intend to do with this environment. By design, a contact can only be a member of a single tenant, which locks them down from being able to see or interact with other tenants (see Can affected end user belong to two tenants for more details on that). If you only had employees who would need to open tickets for a single type of Incident, then multi-tenancy might work (though it's not really designed to do what you're intending), but since you have employees who may need access to multiple ticket types, tenancy might not be the best option.

If I understand correctly, your main concern is that employees will be able to see the categories for CRM, ERP, Helpdesk, and so forth, even if they wouldn't necessarily have a reason to open tickets under those categories. The easiest answer here is likely to have users not select categories that don't apply to their ticket and/or job role - this requires no customization or major changes to the environment, but doesn't really address your problem. If you're set on making a change, it may be possible to have a pdm_if set up on each of those links to only display if the user is a member of a particular group (e.g. groups like CanOpenCRMIncidents, CanOpenHelpdeskIncidents), since contacts can be members of multiple groups. While I don't have the details on how to implement such a customization, I'm sure other community members can chime in with their ideas.

Thanks Johse for the advise.

Raghu.Rudraraju Jon_Israel Alex_Perretti appreciate if you guys also put ur input.

Hi Aamir,

Do you have a clear-cut way to determine which users need to have access to which categories? If yes, then the simplest way to address your requirement is to create multiple variations of the Employee role and then apply data-partitions to them in order to restrict the view of categories the different roles are not authorized to see.

===

Kind Regards,

Brian

Hello Aamir,

Sean and Brian have covered the main points.

Multi-Tenancy is not the best fit to this situation. 

Almost by definition, an Employee will be a member of a single Tenant.  

The higher level Analysts span across multiple Tenants, but the Employees typically won't be doing this.

Also, the key principal of Multi-Tenancy is that one Tenant is locked out of the data for other Tenants. This doesn't sound like what you really want.

You spoke about narrowing down Access Rights by Category.

So carefully setup your Categories, and assign Data Partitions in particular, then Roles and Access Rights to leverage off these. It is also the easiest method to implement from where you are, as Data Partitions can be applied over the top of Categories a lot more easily than moving 10,000 users to different Tenants.

It is also a little unusual to be granting Employees access to Change Orders. (Also to both Requests and Incidents. Organisations usually standardise on one or the other for Employees.) Typically an Employee would create a Call Request/Incident, which would then kick off a Change Order process behind the scenes. If you wish to maintain this Category distinction, then you'll have to extend the logic to Change Orders as well. I would consider if you really need it though at the Employee level.

Finally, you'll need to consider what happens if the ticket is assigned to a Category outside of the ones that the Employee has access to. Do they still get View rights to this, or will they not see it at all? 

Thanks, Kyle_R.