Current trend seen across many enterprises is to decompose complex business processes across multiple smaller interconnected applications. Previously widely used approach to create one big application to handle all processes inside the enterprise is not efficient enough (not scalable solution and difficult to maintain). What we see nowadays are clients creating many smaller apps deployed on one Pega instance to cover the business requirements. Those apps are interconnected and exchange information between themselves.

Users are likely to be switching between apps frequently to achieve business outcomes or simply one user uses two separate not connected apps as he or she is a part of a department or unit using multiple apps for different business needs.

Supporting this need is a bit problematic in ootb Pega. One of the limiting factors is that ‘Work’ configuration present on operator record is global for a given user and not specific per application to which user has access (See operator_config picture attached).

Current data modeling is as follows:

• 1 user can have access to multiple applications – Access Group configuration on operator record
• 1 user has 1 ‘Work’ configuration – present on operator records disregarding number of application that he or she belongs to (set by Access Group configuration)

And here is the main problem. Let’s imagine situation that one operator has access to two totally unrelated apps, application A and B. Operator has of course assigned two Access Groups and as the applications are not related (created for different business purposes) user has been assigned to two different work groups X and Y.

WG X makes sense only for application A while work group Y makes only sense for application B. When user has default WG set to X and logins to app B there is a problem. WG X make no sense for app B it has only meaning in context of application A.

When going to dashboard in app B user has an active WG set to X and has to change its WG manually to Y to see a proper data for application B and not application A. With dashboards it is quite simple as they utilize Active Workgroup concept. During logon Active Workgroup is taken from operator profile and stored on  a clipboard page. Dashboard use this clipboard value as context so it is enough to change data on clipboard to see an effect on screen.

Unfortunately switching active work group in a dashboard is not solving all the issues. While we switch context for dashboard (change of a property value in clipboard) default WG on operator profile (so entry on database table) stays unchanged so any report definition will return WG which does not make sense for application B (as the default WG is still X which makes sense only for app A). This might be a major restriction when we would like to:

• Route work basing on work group – report can show active WG from data base table (pr_operators) which is from other application
• Configure ABAC security basing on work group – the same as above

Work Groups are just an example, we can imagine situations when other configurations on ‘Work’ tab shall depend on current application:

• Work queues setup
• Substitute operators

Suggestions is to introduce intermediate object that will hold operator configuration for operator per Access Group that he belongs to. This will facilitate setting parameters specific for user per given application to which she or he has access  (See proposed_modelling picture attached).

In most cases relaying on data loaded into clipboard are sufficient but as shown above there are situations where you need the data per application to be present in database. While larger clients can afford implementation of such change as custom by means of project implementation teams, I believe it is something that shall be considered as a future enhancement for product (for reasons mentioned in first paragraph).