Entitlement Management Workflow
Day-2 operations — post-onboarding user entitlement changes without a full re-onboarding cycle.
Table of Contents
11.4 Entitlement Management
%%{init: {'theme': 'base'}}%%
flowchart TD
classDef startEnd fill:#2d6a4f,stroke:#1b4332,color:#ffffff,font-weight:bold
classDef system fill:#1d3557,stroke:#a8dadc,color:#ffffff
classDef gateway fill:#457b9d,stroke:#1d3557,color:#ffffff
classDef complete fill:#1b4332,stroke:#52b788,color:#ffffff,font-weight:bold
EStart(["▶ EntitlementManagementWorkflow\nRequest: clientId + changes[]"]):::startEnd
Lookup["getCurrentEntitlements\nTreasury Platform read"]:::system
Validate["validateEntitlementChanges\nBusiness rules · conflict detection"]:::system
ApplyTM["updateTreasuryPlatform\nApply entitlement changes"]:::system
DBCheck{"Digital Banking\nchanges needed?"}:::gateway
ApplyDB["updateDigitalBankingPlatform\nApply Digital Banking changes"]:::system
Notify["notifyClient\nAudit event written"]:::system
EEnd(["■ Complete"]):::complete
EStart --> Lookup --> Validate --> ApplyTM --> DBCheck
DBCheck -- "Yes" --> ApplyDB --> Notify --> EEnd
DBCheck -- "No — skip" --> Notify --> EEnd
Node key 🟦 Automated system activity · 🔷 Decision gateway
What Entitlement Management Covers
After a client is onboarded, day-to-day banking operations generate ongoing entitlement change requests:
- Adding or removing treasury users
- Changing transaction limits (Wire, ACH, Positive Pay thresholds)
- Modifying approval workflows (who can approve which transaction types)
- Adding new accounts to existing product entitlements
These changes go through the EntitlementManagementWorkflow — a simpler, faster workflow than the full onboarding flow, but still durable and auditable.
Workflow Steps
1. getCurrentEntitlements
Calls the treasury-platform-adapter to retrieve the client’s current entitlement state. This is the baseline against which the requested changes are validated.
2. validateEntitlementChanges
Business rule validation:
- Checks that requested limits don’t exceed product-level maximums
- Detects conflicts (e.g., adding a user with conflicting dual-control approval roles)
- Validates that accounts being entitled exist in the Core Banking System
On validation failure, the workflow returns an error — no changes are applied.
3. updateTreasuryPlatform
Applies the validated changes to the Treasury Management Platform via the treasury-platform-adapter. Uses the same circuit breaker and retry pattern as all integration adapters.
4. updateDigitalBankingPlatform (conditional)
If the entitlement changes include digital channel access (user additions/removals, limit changes visible in the Anchita Digital Banking Portal), the anchita-portal-adapter is called to synchronise user permissions and feature access. The gateway checks whether the change set includes digital platform fields.
5. notifyClient
Sends confirmation to the client’s primary contact and writes an immutable audit_events row recording the change, who requested it, who approved it (if applicable), and what changed.
Design Note
This workflow is intentionally simple — no human task signals, no child workflow hierarchy, no AI agent involvement. It is the operational backbone of day-2 treasury management, and simplicity is a feature.