Component: Manual Activities

Component: Manual Activities

Description

Manual Activities are user-initiated actions that capture intent, decisions, or outcomes and trigger downstream behaviour in PCC. They are used to:

• Record customer interactions and decisions

• Initiate treatments or state changes

• Capture audit-relevant actions performed by a specific user

• Trigger routes, tasks, events, or controls

In PCC, manual activities are a core system construct. Regardless of where they are initiated, they must:

• Exist in PCC

• Be executed and stored in PCC

• Record the acting user

• Trigger downstream PCC behaviour consistently

This creates a key design choice around where the user experience lives, not whether PCC remains the source of truth.

Option 1: Continue on PCC Upgrade Plan

Rebuild manual activities using PCC 2.4 proprietary screens

Action

• Rebuild all manual activities using PCC 2.4 native screens and widgets.

• Preserve existing activity definitions and sequencing.

• Require all user interaction to occur within PCC.

Target State Score

2 / 5

Change Impact

5 / 5

• Entirely new PCC screens and interaction patterns.

• High retraining requirement.

• Significant disruption for users.

Business Benefit

1 / 5

• No meaningful uplift in usability or role clarity.

• Manual activities remain tightly coupled to PCC UX.

What this option gets

• Fully supported, standard PCC implementation.

• Clear alignment with vendor tooling.

• No ambiguity around execution or audit.

What this option does not get

• No decoupling of UX from PCC.

• No improvement in delegation or role-based interaction.

• No reduction in PCC screen dependency.

• Continues to force users into PCC for actions better handled elsewhere.

Key Risks and Considerations

Business Risk

• High change fatigue with limited perceived benefit.

• Manual activities continue to reflect system constraints rather than user roles.

Delivery Risk

• Heavy dependency on PCC configuration effort.

• High UAT volumes driven by UX complexity.

Accelerator

• Limited.

• PCC configuration effort remains the critical path.

Option 2: Pivot to Target State (Preferred)

Expose PCC manual activities through decoupled UX (Mini Apps)

Action

• Retain all manual activity definitions in PCC.

• Expose existing PCC manual activities through a decoupled UX, such as Mini Apps.

• Trigger activities via backend integration while:

  • recording the acting user

  • storing the activity in PCC

  • allowing PCC to respond exactly as if the activity were executed natively

• Do not redesign activities; reuse the existing activity catalogue.

• Rationalise the activity list by:

  • removing activities that belong in other systems (e.g. provisioning, address changes)

  • reducing duplication and misuse

Target State Score

5 / 5

Change Impact

4 / 5

• Change in how users perform activities, not what activities exist.

• Improved role-based UX and delegation.

• More intuitive workflows for different user groups.

Business Benefit

5 / 5

• Decouples user experience from PCC constraints.

• Enables better role design and delegation.

• Reduces PCC screen usage without losing audit integrity.

• PCC continues to behave exactly as expected, with:

  • full audit trail

  • consistent downstream behaviour

• Supports alignment with other Mini Apps and future platforms.

What this option gets

• PCC remains the single source of truth for activities.

• Users interact through a cleaner, role-appropriate UX.

• Improved consistency and quality of manual activity execution.

• Reduced need to retrain users on PCC-specific screens.

• Opportunity to rationalise and clean up the manual activity set.

What this option does not get

• Does not remove the need to maintain activities in PCC.

• Requires careful integration design.

• Does not eliminate all complexity.

Key Risks and Considerations

Business Risk

• Requires clear governance over which activities are exposed externally.

• Risk of inconsistent usage if UX design is not disciplined.

Delivery Risk

• Risk if backend APIs are not available to:

  • trigger activities

  • record acting user

  • store activity correctly in PCC

• Additional complexity to ensure PCC audit and security models are preserved.

• Requires careful testing to ensure PCC responds identically to native execution.

Note: There are established integration patterns to address this, but it is non-trivial and must be designed deliberately.

Accelerator

• Cursor can:

  • inventory and rationalise manual activities

  • identify candidates for removal or relocation to other systems

  • design the decoupled UX patterns

  • support backend integration design

• Decoupling avoids rebuilding activities in PCC proprietary screens and reduces long-term UX dependency.

Option 3: Tactical Hybrid

Partial PCC UX with limited external exposure

Action

• Retain PCC screens for most manual activities.

• Expose only a small subset externally.

• Operate mixed UX patterns.

Target State Score

2 / 5

Change Impact

3 / 5

• Inconsistent user experience.

• Partial retraining required.

Business Benefit

2 / 5

• Some flexibility.

• No structural simplification.

What this option gets

• Incremental progress.

• Lower upfront integration scope.

What this option does not get

• Clean UX separation.

• Clear role-based interaction model.

• Reduced PCC dependency.

Key Risks and Considerations

Business Risk

• Confusion over where activities should be performed.

• Inconsistent adoption.

Delivery Risk

• Increased support complexity.

• Harder to maintain over time.

Accelerator

• Limited.

• Often becomes a dead-end architecture.

Overall Assessment

For Manual Activities, Option 2 is the strongest and most future-safe approach.

• Option 1 locks users into PCC UX with no uplift.

• Option 3 creates inconsistency.

• Option 2 preserves PCC as the system of record while enabling better UX, delegation, and role clarity.