Joe, None of our service desk agents have unrestricted access. For those that support multiple tenants, they have access to just those companies, but the issue lies in the fact that the Assigned Support Group menu does not qualify against who the Customer's Company is, the qualification on the menu is just 'Status'="Enabled", since they have access to multiple tenants, the menu selection will show all the support groups they are authorized to see, irrespective of what company the Customer's Company is.
--Brian From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Wednesday, October 16, 2013 10:00 PM To: arslist@ARSLIST.ORG Subject: Re: EXT :Re: Filter Assigned Group Menu by Contact Compay ** Can't you do that simply by removing Unrestricted Access and granting access to only the companies that the agents should see with restricted access? Joe ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Kalicki, Brian J (IS) Sent: Wednesday, October 16, 2013 4:26 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: EXT :Re: Filter Assigned Group Menu by Contact Compay Our Service Desk supports multiple tenants within Remedy. For example, we have Company A, B and C. Service Desk Agent 1 supports Company A and C, while Service Desk Agent 2 supports Company A, B and C. In relation to just Incidents (for this example), out of the box, if you have access to multiple tenants(companies), the Assigned Group menu gives you all the companies you have access to, therefor, you are able to create an Incident ticket for Customer in Company A and assign the ticket to a support group in Company B. We have workflow today that checks the Assigned Support Company against the Contact Company, which is checked on Submit and Modify. What I am driving to is making it cleaner and have Remedy display the relevant information for the current Contact Company. With that, taking the example above, when Service Desk Agent 1 creates an Incident ticket for Customer in Company A, the support group menu will only show support groups for Company A, it shouldn't show support groups for Company C. Brian Kalicki Remedy AR System Administrator Northrop Grumman Information Systems IT Systems and Solutions From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Wednesday, October 16, 2013 2:00 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: EXT :Re: Filter Assigned Group Menu by Contact Compay ** No if you have a search menu and want to include that field in the search menu qualification, it has to be a data field. What really is your business requirement that you need a functionality such as this? Joe ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Kalicki, Brian J (IS) Sent: Wednesday, October 16, 2013 10:57 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Re: EXT :Re: Filter Assigned Group Menu by Contact Compay Joe, Thank you for some input, unfortunately, I can't include a display only field in the menu qualification for the Assigned Group menu correct? Last time I tried this for a different effort, it didn't work. --Brian From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Joe D'Souza Sent: Wednesday, October 16, 2013 1:45 AM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: EXT :Re: Filter Assigned Group Menu by Contact Compay ** If I have understood you right, you do not want the value saved to the DB and hence cleared after the transaction. Why not have that field as a Display Only field? Joe ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Kalicki, Brian J (IS) Sent: Tuesday, October 15, 2013 6:55 PM To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> Subject: Filter Assigned Group Menu by Contact Compay Good evening List, I am finally getting around to taking a look at our current customizations surrounding "multi-tenancy". In our case, we have a leveraged service desk model, where an individual at the call center has access to multiple tenants. So far, we have done a pretty good job of creating workflow (only for Incidents at this time) to not allow an individual with access to multiple tenants to "cross company boundaries", primary example is Assigned Group; currently, on submit or modify, workflow checks Contact Company against Assigned Support Company, if they match, Ok, if not, error. This particular workflow is causing other issues, so I have decided to look into the possibility of filtering the Assigned Group menu for support groups related to the selected Contact Company. Here is what I have done so far: 1. Created a custom field called "CompanyChk" and placed this field on CTM:Support Group (This will be referred to as the "check field") 2. Created an ActiveLink on HPD:Help Desk, on Menu selection of Contact Company a. Push Contact Company to the check field on CTM:Support Group 3. Modified the menu qualification on HPD:Help Desk; Assigned Group, to check Company = CompanyChk At this point, it works as intended, but since I am not clearing the check field, the next person who has access to the particular company will see the support groups even if the Contact Company is different for the ticket they are creating. This also goes for tickets they are modifying after submit. I am afraid that if I put in more workflow to clear the check field, there will be A LOT of write activities to the database and cause performance issues. I believe this to be true as I will have to add workflow to clear it after, say Submit, but then push the contact company again on modify. Any ideas or thoughts would be appreciated as I have not been able to find anyone else who has attempted the same. Regards, --Brian _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "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"