Jira Automation is powerful until you need a step that only your company understands—pull requirements from an internal API, enrich an issue from ERP, or call a risk score. That is when a custom Forge Automation action beats another fragile “Send web request” step.
What you are building
A Forge app that registers an action module and an automation:actionProvider, so admins can pick your action in the Automation rule builder, configure inputs, and pass smart values like {{issue.key}}.
Manifest building blocks
action— name, description,actionVerb(GET/CREATE/UPDATE/…), inputs, optional outputs.automation:actionProvider— lists which actions appear in Automation.function(or remote endpoint) — executes when the rule fires.configUI — the form admins see when configuring the action.
Design the contract first
- List required inputs (issue key, project, custom field ids).
- Define outputs other rule steps can consume.
- Document failure modes (timeout, 4xx from upstream, missing permissions).
- Version the contract—breaking output names breaks every rule using the action.
Implementation tips
- Keep the action idempotent where possible; Automation can retry.
- Validate smart-value inputs; never assume issue keys are well-formed.
- Prefer app scopes with least privilege; test as a non-admin rule actor.
- Log a correlation id into an issue comment or property for support.
When not to build an action
If a native Automation component or a Marketplace action already covers 90% of the need, configure that first. Custom actions shine for proprietary systems and compliance-sensitive calls you will not put in a generic webhook.
Go-live checklist
- Sandbox rule with a dedicated test project.
- Permission matrix for the rule actor.
- Load test upstream SLAs under peak create volume.
- Runbook for rotating secrets used by the action.
Need this built? HostHob ships production integrations and Marketplace-ready apps from Rotterdam. See our services or Build a custom Automation action.