We are using Pega v25.1.3 with Constellation UI.
I would like to control which operators ,users can mention in Pulse. It appears that D_pyC11nOperatorsList is the data page used for operator lookups; however, this data page is shared across multiple use cases like Followers, StakeHolders etc.
My requirement is to restrict the list of users available for Pulse mentions based on organizational work group without impacting other functionality. Please let us know if this is feasible .
you’ll need to specialize the mention behaviour rather than trying to filter the shared D_pyC11nOperatorsList data page directly (since that DP is used across for Followers, Stakeholders, Mentions etc.). Better approach is to keep the base data page intact and introduce a context-aware filtering layer for Pulse only.
For hiding mentions entirely, Pega provides pyExtendDefaultSettings in Pega-Ext-Mentions-Users / Pega-Ext-Mentions-Cases where you can set .pyHideMentions = true. For filtering the operator list in Pulse, you need a custom data page/report that is aware of the case/work group context, then wire that into Pulse via a custom feed/extension
Do you have a suggestion how to implement a different datapage for pulse mentions that takes the context of the case into account?
@schos1 In Constellation, the front-end Pulse component interacts directly with the DX API service layer, which has ‘D_pyC11nOperatorsList’ hardcoded in it. Because Pega does not expose a UI extension point or Data Transform in Pega-Ext-Mentions-Users to swap D_pyC11nOperatorsList for a custom Data Page name, any customization must be handled either by customizing D_pyC11nOperatorsList itself or by controlling data visibility at the platform layer.
Approach# 1: Overriding D_pyC11nOperatorsList with Conditional Alternate Sources
Save As D_pyC11nOperatorsList into your application ruleset and configure an Alternate Data Source driven by a When rule or parameter check. Add a conditional Source 1 pointing to a custom Report Definition filtered by Work Group (using pxRequestor.pxWorkGroup or OperatorID.pyWorkGroup). Set Source 2 (Otherwise) to the standard pyOperatorsForCurrentApplication report.
Approach# 2: Specialize on the Report Definition
Keep D_pyC11nOperatorsList intact and hook into the report extension. Specialize or override the Report Definition to WorkGroup by Circumstancing it.
Approach# 3: Attribute-Based Access Control (ABAC) / Data Security Policies
( havent verified this but should work in theory)
Apply an ABAC Read Policy on the Data-Admin-Operator-ID class to filter operator record visibility at the platform security layer.
Define an Access Control Policy Condition that matches the operator’s Work Group against pxRequestor.pxWorkGroup.
@RaviChandraJonnavithula In approach 1, Since Pulse’s @mention operator picker invokes D_pyC11nOperatorsList with no custom parameters (it’s an OOTB component I can’t modify or extend), how can a When rule on that Data Page’s Alternate Data Source detect that a given invocation specifically came from Pulse — rather than from any other feature that might reference the same Data Page — so I can apply Work Group filtering only in the Pulse context?
@Chaitanya_G A When rule on an Alternate Data Source cannot inherently determine that D_pyC11nOperatorsList was called by the Pulse @mention picker. It can only evaluate the parameters and clipboard/requestor context supplied to that invocation.
So, you might have to trace the Pulse lookup and compare it with a Followers/Stakeholders lookup. When Constellation UI fires a mention lookup, the underlying REST request includes query or header context that gets populated onto the pxRequestor system page. Create a When rule (e.g. IsPulseMentionContext).. and in that when rule, evaluate pxRequestor.pyRequestHeader or some query parameters passed during the DX API execution.
Additionally, when Pega loads a DP, the engine maintains the active call stack on pxThread. After tracing the Pulse request above, you can additionally evaluate the primary activity or API service name currently executing using pxThread.pySystemActivity or pxThread.pxCurrentActivity.
If pxThread.pySystemActivity matches a Pulse feed/mention API activity,
then IsPulseMentionContext = true (triggers Source 1 with Work Group filtering)..
else return false (falls back to Source 2 for standard operator lists).
@JayaN17847163 I’d like to move this to User Experience, to go with the other Constellation posts.
However, you are not a member, if you can join then that will allow me to move this (only members can reply to User Experience posts, so you would no longer be able to reply).
Let me know when you join and I’ll move this.
