Action Providers are how ctxgraph evolves without getting brittle
Add external actions directly to the case experience, show them only when they are relevant, and keep execution under policy, permissions, and auditability. This is the bridge between the workflow UI and the systems where real work happens.
discover → authorize → execute → reflect
Move fast without turning the product into an integration maze
Teams should not need a core product release every time a new downstream action becomes important. Action Providers keep the platform extensible while preserving a clean operational boundary around permissions, execution, and auditability.
Use the protocol surface that fits your stack instead of hand-rolling every discovery and execution contract.
The platform remains the place where permissions and operator context are enforced, even when the action runs elsewhere.
export async function discover(ctx) {
// Only show the action when the ticket context says it matters.
if (ctx.ticket.issue_type?.name !== 'Payment Reprocess') {
return [];
}
return [{
id: 'reprocess-payment',
label: 'Reprocess Payment',
description: 'Run the external reprocess flow from the ticket.',
requires_confirmation: true,
}];
}
export async function execute(actionId, ctx) {
// The platform stays responsible for permissions and auditability.
return {
success: true,
message: 'Payment reprocess submitted.',
effects: {
add_comment: {
content: 'External reprocess started from Action Provider.',
is_public: false,
},
change_status: {
status: 'In Progress',
},
},
};
}Questions developers and platform teams ask
These answers focus on why Action Providers are a safer extensibility model than sprinkling raw integrations and untracked buttons around the operation.
What is an Action Provider?
An Action Provider is an external service that can expose ticket-specific actions back into ctxgraph. It lets the product discover the next relevant downstream step without forcing every business workflow into the core application.
How quickly can a team add a new action?
The integration surface is intentionally small: discover available actions for a ticket, then execute an action when the operator chooses it. That keeps the amount of platform-specific code low while still letting teams add meaningful workflow extensions quickly.
How are provider calls authenticated?
Provider calls use configured authentication modes such as HMAC, API keys, or bearer tokens, and the platform routes execution through its own control layer instead of exposing a raw button-to-webhook model.
Can providers safely update ticket state?
Yes, but through controlled effects. Providers can return side effects such as comments, status changes, or structured updates, and the platform remains responsible for how those effects are applied and recorded.
What happens when a provider fails?
Failure is treated as part of the operational truth. The platform preserves execution history so the team can see that the action was attempted, what returned, and why the expected outcome did not occur.
Bring one external action into the case experience
Pick the workflow your operators rely on most and we can show how an Action Provider would expose it safely inside ctxgraph.