Question

Support for multiple applications

I have 2 different case types in the same class group.

1 separate group of users work on one case type and another on the other case type but they want to be able to see each others cases in readonly/review mode. Wouldn't that mean I need to have one application with all rulesets for both case types in the application/ruleset stack so that if users of one case type open cases from the other case type the rules for that other case type could be resolved to? The downside of having just 1 application is that there would be more potential for accidently breaking each other. One application and case type are already being worked on in production and I am developing the other case type now.

***Edited by Moderator Marissa to update platform capability tags****

Comments

Keep up to date on this post and subscribe to comments

October 22, 2019 - 10:04am

You should be able to configure different access groups that can access the same application but have different access permissions for the 2 different case types using Access Manager.

October 22, 2019 - 10:26am
Response to Marc Alderman

Yeah that's the path I was going down but I saw something peculiar where I am able to open a case in review mode through "Recents" gadget that was created from a different application than the one I was currently logged into and it came up fine in Review harness.  It looks like when I trace it it does an application switch for that thread when you click on it. So that's when I was not sure if I really needed a single application or not even though I would have my own custom gadget for users to search for cases for each case type.  So because of how recents gadget is working I was unsure whether I would still need one single application.

October 22, 2019 - 10:59am
Response to TerranceK4053

What do you mean by "application switch"? Does an access group of the user changed when you click on the CaseID in "Recents" section?

Generally, the solution should be:

1. if you have a workgroup with sub classes like:

Work-Brilliant-Group

Work-Brilliant-Group-CaseAOldGoodCase

Work-Brilliant-Group-CaseBNewbie

2. Then you should consider your access groups:

2.1 Firstly, AG_A and AG_B may point to the same application

2.2 Add different roles to AG_A and AG_B, for example, CaseProcessorA (for AG_A) and CaseProcessorB (for AG_B).

2.3.1 In the role CaseProcessorA setup access to classes:

         - Work-Brilliant-Group-CaseAOldGoodCase: All fives (read, write, reporting, delete rules and so on)

         - Work-Brilliant-Group-CaseBNewbie: Only Read access must be 5, others = 0

2.3.2 Vise versa for CaseProcessorB

October 22, 2019 - 12:49pm
Response to vaspoz

 

I believe it called AppliationProfileSetup.  It allowed me to open the case in review harness with UI rules that weren't in my ruleset stack.