Can Pega Pulse be used outside standard case-level context and customized for sub-entity threads?

General
1

Hi All,

I have a design question regarding the architectural scope and intended usage of Pega Pulse.

From documentation and behavior observed in applications:
• Pulse provides an activity stream (posts, replies, attachments).
• It can be embedded using @baseclass.pxActivityStream.
• It appears to bind to an object context using an internal key (Indirect Object Key).
• Users can post even when a case is unlocked, suggesting Pulse is not strictly tied to case locking or flow execution.
• Pulse data is persisted separately (e.g., PegaSocial-Message) and associated to an object.

Fundamental Question

Is Pulse inherently designed to be:

  1. Case-scoped only (1:1 with a work object pzInsKey),
    or
  2. Object-scoped, meaning it can technically bind to any object context if a different key is provided?

In other words:

Can Pulse be embedded anywhere in an application and configured to bind to a custom object (or custom key) context rather than the primary case instance?

⸻

My Use Case (Generalized)

Within a single case, I have multiple sub-entities (e.g., line items).

Each sub-entity needs:
• Its own independent comment thread
• Threaded replies
• Isolation from other threads
• Reportability

Conceptually, this means multiple Pulse feeds within the same case — each tied to a different logical object.

⸻

Configuration Questions

If Pulse is object-scoped rather than strictly case-scoped:

  1. Can pxActivityStream (or other section) be configured to use a custom Indirect Object Key dynamically?
  2. Is there a supported configuration approach (parameters, extension points) to bind Pulse to a sub-entity identifier instead of the case pzInsKey?
  3. Would such feeds remain isolated from the parent case feed?
  4. Are there official guidelines or documentation covering this usage pattern?
  5. Extend the existing pulse instance class?

⸻

I am trying to determine whether this is a supported design pattern before exploring implementation options.

Appreciate any technical clarification or references.

Thanks.

2 Likes
2

Pulse is conceptually context‑scoped, not strictly “case‑scoped”, and Pega exposes APIs that let you bind it to case, rule, operator, or a custom context key.

however, the standard UI (pxActivityStream/pxContextFeed) is primarily delivered and supported for case/work‑object use and anything beyond that is an “advanced” pattern you need to align with the documented Pulse APIs

Pulse messages are stored as instances of PegaSocial-Message, and each message has a context key (e.g: pyIndirectObject / related context properties) that logically associates the message with some object. In the out‑of‑the‑box case feed, this context key is set to the case/work object handle (pzInsKey), which is why you see a 1:1 feed per case even if the case is not locked

The pxContextFeed gadget is the recommended starting point; it can be embedded in your own sections and is documented as a generic Pulse UI for a specific context. That gadget calls D_pxPosts, which supports custom context types in addition to case/rule/operator; you can build your own wrapper section/activity that sets the context parameters.

Also, You generally do not extend PegaSocial‑Message itself. instead you extend through configuration- new context type/key, reports and data pages on PegaSocial‑Message filtered by that context, and your own UI built on the documented Pulse APIs