P4A DocumentationDeploying a policy
Publish an approved policy to your Anypoint organisation through a registered Anypoint connection.
Overview
Once your policy has been approved and you have at least one Anypoint connection registered, P4A can publish the policy to your Anypoint organisation on your behalf. This page covers the deploy flow itself — selecting where to deploy, choosing Publish vs Release, and tracking the result. If you don't have a connection yet, set one up first via Connecting your Anypoint ORG.
Triggering a deployment
You deploy any approved policy from the policy detail page. Click the Deploy action and a dialog opens with everything the build pipeline needs to know.
Fields in the Deploy dialog
- Workspace — the workspace whose connections you want to deploy through. Defaults to your personal workspace; switch to a shared workspace to scope the connection picker to that workspace's shared connections. See Using workspaces for who can link a connection into a shared workspace.
- Anypoint Connection — one of the Connected Apps reachable from the selected workspace. The list shows the connection's display name and host region (US, EU, etc.).
- Target business groups — the Anypoint business groups to publish into. Each selected group becomes its own deployment row and its own Exchange asset, all running in parallel. Pick one for a single-org deploy or several to fan out.
- Source ref — the git ref of your policy repository to build from: a branch, a tag, or a full commit SHA. The field is a free-text combobox — start typing and P4A suggests matching branches it pre-loaded from GitHub, but you can type any tag or commit SHA the suggestions don't list (handy for pinning a deploy to an exact commit, or when the repo has more than 100 branches and the list is truncated). The ref is validated against GitHub before the build is enqueued. Defaults to the ref pinned in the policy URL or the repo's default branch.
- Deploy mode — see the next section.
- Clean up old DEV versions — optional checkbox. When set, after a successful Publish run P4A removes older DEV asset versions from Exchange and keeps only the version this run produced. Has no effect on Release runs.
Deploy mode: Publish vs Release
Deploy mode is the most consequential field in the dialog, and the two modes are mutually exclusive (radio buttons):
| Publish | Release | |
|---|---|---|
| Exchange asset version label | Timestamped DEV version (e.g. 1.2.0-20260616153000) | Stable release (e.g. 1.2.0) |
| Intended audience | Yourself / your team for testing in a sandbox business group | Consumers across your Anypoint organisation |
| Mutability | Each Publish creates a new DEV version; older DEVs can be cleaned up via the checkbox above | Stable, immutable once released — bump the policy version for the next release |
| When to use | Iterating on the policy, smoke-testing a fix, validating a branch, tag, or specific commit | You're confident the policy is ready for downstream API instances |
In short: Publish is for "let me try this out", Release is for "this is the version I want my consumers to apply." A policy can have many Publishes and few Releases. The build pipeline runs make publish for the Publish mode and make release for the Release mode, once per selected business group.
When you click Deploy, P4A enqueues one build job per selected business group. Each job clones your repository at the chosen ref, runs the corresponding make target, and publishes the resulting Exchange asset to that business group. Once expanded, each run in a deployment's history shows the git ref it built from next to its timestamp. You can monitor progress per row from My Deployments below.
Watching a deployment run
While a deployment is in flight, the corresponding row in My Deployments shows a pending (or in-progress) status and exposes a live build-log stream — useful for catching PDK build failures or Anypoint Exchange publish errors without leaving the portal. Expand the row to see the log output update in real time as the worker progresses through clone → build → publish.
A policy config property must not be named after a Rust reserved word (for example type, match, fn, mod, impl, struct, move, ref, use, loop, or where). If one is, the build fails and the log names the offending property — rename it (for example type → fieldType) in your policy's gcl.yaml and re-deploy.
Documentation page on the Exchange asset
When a deploy succeeds, P4A also publishes a documentation page to the resulting Exchange asset, so the listing carries a real description — the policy's name, summary, and links back to its source and P4A portal page — instead of an empty page. This happens automatically; there's nothing extra to enable.
Publishing the documentation page is best-effort and never blocks the deploy: if the page fails to publish, the asset is still deployed and usable. When that happens, the deployment row shows a small docs page not published note. It means the Exchange listing has no description page even though the deploy itself succeeded — re-deploy to try publishing it again.
Deployment history
The policy detail page lists all past deployment attempts under My Deployments. Each entry shows the target connection and business group, the deployment timestamp, and a status (released, published, pending, failed, deleted). Entries also show the published Exchange asset version they shipped — a single version label (e.g. v1.2.0) for a standard policy, or separate definition and implementation versions (e.g. def v1.2.0 · impl v1.0.0) when the policy publishes its definition and implementation as separate assets. You can filter the list by status, expand any entry to see the build logs that ran for it, jump to the deployed asset on Exchange, or trigger a re-deploy.
Cleaning up failed deployments
A deployment that errors out leaves a failed entry in My Deployments. Once you no longer need its build logs, you can remove it permanently:
- One at a time — expand a
failedentry and choose Delete to remove that single row and its build logs. - All at once — use Delete all failed in the My Deployments header to clear every failed entry you own for the policy in one step.
Both actions ask you to confirm first, and only ever touch your own failed rows — released, published, and pending deployments cannot be deleted this way (cancel or unpublish those instead). Deletion is permanent: the deployment row and its build logs are removed and do not appear in history afterward.