Hi John,
If I understand your dilemma correctly then ITSM 8.1 should be able to handle this scenario with the following assumptions: 1. Support people have "Unrestricted Access" 2. End users have "Restricted Access" to the Company (department) to which they belong In ITSM 8.1 multi-tenancy works as follows: Ø Multi-tenancy is a feature in the BMC Remedy Applications that enables you to control which records and specific configuration data are exposed to a user, based on the user’s permissions. Tenancy is based and controlled at the Company level. Various forms in the BMC Remedy Applications expose one or more Company fields that control the tenancy access for a given record. Ø Row-level security typically works as follows: o On main user facing transactional forms: § Tenancy is based on the Customer Company and/or Process Company defined on the record (sets field 112) § Tenancy is also based on the Support Companies assigned to a record (sets field 60900) o Child forms: § Child form should inherit their parents tenancy permissions o Join forms § Tenancy should be inherited from either the primary or secondary form identified within the join criteria especially if one of the forms is a user facing transactional form Ø Tenancy is implemented using the Row-level Security feature of AR. In summary we determine which groups or roles have access to a request through the permissions on the Request ID field (field ID 1). - In the Remedy Applications this is controlled by the following permissions on field ID 1 § 1000000000 = Unrestricted Access § 7 = Assignee Groups (field 112) § 60900 = Vendor Assignee Groups (field 60900, typically only used for transactional based forms) - These permissions are used to drive the tenancy model in the apps. Both Assignee Groups and Vendor Assignee Groups are referred to as Implicit Groups in AR. - In the apps we assign Company permission groups to these two Implicit Groups to control access to records. Hence our tenancy model is based on Company access. Unrestricted Access permission group is a regular AR permission group. If a form is going to be row-level secured in the Apps (or multi-tenant) we typically assign these three permission groups to field ID 1 on that form. Note, Vendor Assignee Groups (field 60900) typically contains the AR permissions group ID for Support Companies that are assigned to a record (e.g. for Incident that would be the Assigned and Owner Support Company; for Change that would be the Change Coordinator and Manager Support Company, etc.). The Vendor Assignee Groups permission is not required on all forms and it typically found on transactional based forms. - So in order for a user to see a record, on a form that is multi-tenant, they need to either have the Unrestricted Access permission group, which gives them access to all records as this is defined on field ID 1 on all tenant forms OR they need to have access granted by one of the two Implicit Groups. You’re use case in ITSM 8.1 would mean that the customer company is stored in field 112 (Assignee Groups) and the support user company is stored in field 60900 (Vendor Assignee Groups) (on all main transactional forms: incident, problem, change…etc…). Since Field ID 1 on these forms has permissions to both field 112 and 60900 the appropriate people should see the request. Support users should be allowed to see all requests as they have unrestricted access. (hopefully I have understood you’re use case properly ☺) Hope this helps. Regards, Ryan. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of John Marshall Sent: Monday, September 30, 2013 2:28 PM To: arslist@ARSLIST.ORG Subject: Support Company based muti-tenancy I wanted to see if anyone out there can give me some suggestions on how to accomplish the following in the ITSM 8.1 environment WITHOUT any coding changes… I am working for a university that has several departments that would like to use the ITSM in a multi tenancy fashion; so each department would like to have their own set of rules, support groups, etc. and NOT allow the other departments to see their tickets and them not see the other department’s tickets. So far, it sounds like a straight multi-tenancy setup, however the issue here is that ALL the departments would like use the same user base but have their department rules apply. I know that I can use the “Support Company Access Config” to share the people data across the various departments, but then my dilemma is that when a support user select a customer, that customer’s company gets populated with a company which might not be (and probably won’t be) the same company (department) of the support user, so the support user’s company (department) rules will not be applied, it will be the rules associated to the customer's company. Any ideas/suggestions on how to force it to be the support person’s company (department) rules, again, short of coding changes? Thanks for any help/ideas/etc. John _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
<<inline: image001.png>>
