Capability Call
What It Is
A capability call is the continuing record of one requested provider operation. An application asks for a business job, such as authorizing a payment, using a shared contract. The gateway selects an account, attempts the job and retains the result or the uncertainty that remains. Staff see that continuing record as an execution in Activity.
The execution distinguishes the request from each attempt made to deliver it. That distinction matters when a provider is temporarily unavailable or when an answer is lost after delivery. A request identity supplied by the caller connects repeated submissions to the existing operation. The execution identity then follows provider attempts and investigation. A product manager can use this model to ask whether another attempt is safe without assuming that an unanswered request failed.
What It Is Not
A call is different from the invoice, payment or meeting record that motivates it. The owning application remains responsible for that business record and for interpreting completion. An extension invocation supplies customized application behaviour, and a workflow action run records configured work in its host. Either may cause provider work, but its record does not replace the gateway execution.
How It Is Used
Applications use the gateway so business code can request a capability without choosing a provider implementation itself. Administrators configure the account choices and use Explain to investigate selection. Operators inspect execution detail when a call fails or remains uncertain, comparing the attempts, summaries and provider references.
Good operational practice distinguishes an admission refusal from work that may have reached the provider. The former can release an unused request identity; the latter needs investigation. A person who checks the provider’s dashboard can record the result when automatic investigation is exhausted. The Library’s test panel creates the same kind of execution, with a test-account boundary and an initiating person.
Its Facets
Capability contract and binding. The contract defines the request and result, while a scope-specific choice supplies the provider account. These are separate inputs to a call.
Trace and request identity. The trace explains selection checks. The idempotency key links repeat requests to the retained operation and distinguishes changed input.
Attempts. Delivery timing and classified outcomes guide safe repetition. Multiple attempts still belong to one execution.
Settlement and investigation. Unknown outcomes use provider lookup. Exhausted investigation becomes a manual task, and settlement supplies one applicable completion event.
Diagnostics and archive. Safe summaries remain with execution records. Optional payload capture and older-record read-through support support work without making retained payloads a source for console retries.
Test calls. Provider-reported test accounts let administrators see actual gateway work without treating the Library as a general business-operation screen.
How It Relates
The selected connection supplies authentication and a provider implementation. Its installation acceptance limits supported access. Completion travels as an integration event back to the application that initiated the call. A workflow action may request a provider job, but the host’s action record remains its explanation for why that call was made.
What It Could Become
The product should prove concurrent admission, uncertain-outcome settlement and complete circuit opening before relying on a sourced description as operational acceptance. Retry remains disabled in the console because the application owns the original request. Archive expiry and some staff controls are unresolved. The gateway milestone has approved intent and open defects, so documented or observed behaviour does not yet mean that the milestone is accepted.