Skip to content

Exchange Contexts

What this screen is for

An exchange context models one governed business relationship in which cryptographic work happens: card embossing with a card brand, collections with an outsourcing provider, reporting to a regulator, or an internal pipeline. It records the application that owns the relationship, the counterparty, the direction the data flows and the business purpose.

Capability grants can be scoped to a context, so the same actor can be authorized differently in different relationships, and one action on the context stops or resumes all of that work at once. Operations performed in a context carry its counterparty and direction into the audit trail.

What must exist first

This screen is for tenants that compose authorization by hand. It is not offered to SIMPLE tenants: a SIMPLE tenant uses Internal Use Cases, which create the exchange context each use case needs.

Before you work here:

  • An application to own the context. The application choice is filled with your permission to list applications; without it the list is empty and no context can be created.
  • The permission to list exchange contexts, which is what shows this screen. Creating, editing, suspending, reactivating, closing and deleting a context are further permissions, each held separately.

Decisions you make here

Opening a context

Selecting a context opens its detail in a panel beside the list, with the tabs Info, Edit (with the permission to update contexts), Lifecycle and Activity, in that order.

Info shows the context's record, including its Counterparty type — the type's name with its code, or "—" when the context has none — when it was created (Created At) and when it was last changed (Updated). The list shows the same Counterparty type in its own column, which does not sort.

Creating a context

With the permission to create exchange contexts, New Exchange Context asks for:

  • Parent Application, required: the application that owns the relationship.
  • Name, required and unique within that application.
  • Direction, required: OUTBOUND when you send data to the counterparty, INBOUND when you receive it, BIDIRECTIONAL for both, or INTERNAL when the flow stays inside your tenant.
  • Sensitivity: the classification of the data exchanged, PUBLIC, INTERNAL, RESTRICTED or CONFIDENTIAL, with INTERNAL as the default. It is recorded for your own governance; the platform does not restrict operations by it.
  • Counterparty, an optional Counterparty Type from your tenant's catalog, a Display Name and a Business Purpose.

The context is active as soon as it is created. Its application, name and direction cannot be changed afterwards, so settle them before you create it.

Editing a context

With the permission to update exchange contexts, the Edit tab of a context's detail changes its display name, description, counterparty, counterparty type, business purpose and sensitivity. Emptying a text field there keeps its previous value rather than clearing it.

Counterparty type offers your tenant's catalog, platform types marked Platform, and None. Choosing None removes the context's type; leaving the type as it is keeps it. When the catalog cannot be read, the choice is disabled and says whether you lack the permission to read it or the read failed, and the current type is kept.

Suspending and reactivating

With the permission to suspend exchange contexts, Suspend on the Lifecycle tab stops the relationship at once: every operation bound to the context is refused, whichever grant would otherwise authorize it. You must give a Reason for suspension, which is recorded in the audit trail against your account.

Nothing is revoked by a suspension. With the permission to resume exchange contexts, Reactivate returns a suspended context to active, and the same grants authorize again. Suspending the context is the fast lever precisely because it is checked on every request. Withdrawing a grant is not: a token the actor already holds keeps the operation permission that grant conferred for the rest of its life, up to 900 seconds, and the platform's grant cache can serve the grant for up to 300 seconds more.

Closing a context

With the permission to close exchange contexts, Close (terminal) ends the relationship permanently, whether the context is active or suspended. A closed context can never be reactivated. Grants scoped to it are not revoked; they stop authorizing anything, and they stay listed until you revoke them.

Suspend when the relationship will resume. Close when it has ended.

Deleting a context

With the permission to delete exchange contexts, Delete (permanent) is offered only for a closed context, and you confirm it by typing the context's name. The deletion is refused while active capability grants or cryptographic exchanges still reference the context, so revoke those first. A deleted context cannot be restored.

Reviewing activity

The Activity tab of a context's detail shows the operations performed inside the context and the changes made to it, such as its creation, edits, suspensions, reactivations and closure. All, Administration and Usage choose between both, the changes only, and the operations only. It is the same view the Exchange Topology shows for the context, and its reads start when you open the tab.

Reading operations and reading changes are separate audit permissions: when one is refused or fails, the tab says which and still shows the other.

Each kind states how many of its entries are loaded out of how many it holds, and Load more reads the next ones until the tab says that kind's history is complete. On All, the merged list goes back only as far as both kinds are loaded, and the tab states that date. A next page that fails is stated with Retry and keeps what is loaded; a refused one says so. View in Audit Log opens the Audit Log narrowed to this context over the last 365 days.

How it relates to other screens

Grants are scoped to a context when they are created, and a grant's actor is what performs the operations inside it:

Every context belongs to an application, and deleting that application closes its contexts. The Info tab names that application and opens its detail on the applications screen. When the name cannot be read, because the read is refused or the application no longer exists, it shows the application's identifier marked name not available:

The topology shows the same activity for a context in its detail panel:

Cryptographic exchanges also reference contexts, and one that has not ended blocks the context's deletion. A context is one of the references the cryptographic exchange wizard asks for, so a context created here is what you select there:

Where to read more