Overview
Consume AccessGuard entities, relationships, timeline, presentation, permissions, changes and valid actions through ContextResolver.
Prerequisites
Permissions required
Steps (4)
-
1
Authorize context operations
Grant the consuming application only the required context.resolve*, listAvailableActions, presentation, permissions, subscription, and executeAction operations.
Tips
Validation
Success criteria
-
2
Resolve the source entity
Call context.resolveEntity with an AccessGuard entity type and canonical ID.
Tips
Validation
Success criteria
-
3
Request supporting context
Resolve relationships, timeline, presentation schema, permissions, change topics, and available actions as needed by the consuming UI/workflow.
Tips
Validation
Success criteria
-
4
Execute an allowed action
When the workflow is authorized and the current state exposes an action, call context.executeAction and let AccessGuard re-authorize/update the source record.
Tips
Validation
Success criteria
About this guide
AccessGuard centralizes workspace authentication and customer identity. External websites can use the signed Bridge v2 proxy and JavaScript SDK for registration, login, verification, recovery, token refresh, profile management, protected media, and notification inbox operations.
Inside the workspace, AccessGuard owns users, sessions, verified identities, customer profiles, communication preferences and consent, approval state, KYC documents, risk flags, notification state, audience segments, application operation grants, delegation policies, and trusted context actions. Canonical capabilities are available through Handler and RCP, with selected operations available through Bridge v2.
Configured providers handle downstream delivery and human work: email, SMS, WhatsApp, voice, push, and case/problem operations can be delegated while AccessGuard preserves the identity, authorization, provenance, and customer-policy record.