Skip to main content
When a stack profile is public or shared with your organisation, you can do more than deploy it: open it in the builder, edit it, and send the result to the owning organisation as a suggestion. The owner reviews the diff and either approves it - publishing it as the profile’s next version - or rejects it with a note. The profile itself stays owner-only throughout: a suggestion never changes anything until an owner approves it.
This is how a fix you have proven in production travels back to a shared or public profile without the owner handing out write access - and without exporting YAML and mailing it around. It is also the right lane for the owner’s own updates: a builder draft keeps the version’s input annotations (titles, descriptions, enum choices, and choices that set other inputs), while editing an IaC export and re-importing it re-detects the inputs from the spec, drops those annotations, and creates a separate new profile instead of a new version.

Propose a change to a profile you do not own

Prerequisites

1

Be able to see the profile

Public profiles and profiles shared with your organisation both qualify. Shared profiles carry a “Shared with you” label in your profile list.
2

Not own it

On profiles your organisation owns you have Edit Builder and publish directly; the suggestion lane exists for everyone else’s profiles.

Edit and submit

1

Open the profile and choose Suggest changes

On a profile you do not own, the builder button reads Suggest changes instead of Edit Builder. It opens the stack builder on a draft seeded from the profile’s latest version, held in your own organisation. Choosing it again later resumes the same draft - your organisation has one open suggestion draft per target profile, so a second click never forks a second copy.
2

Edit like any other draft

Change add-ons, manifests, variables, and inputs exactly as in your own profiles. The draft autosaves as you work, and the header shows a readiness chip - Ready to publish, or a count of blockers you can click to see what submit would refuse.
3

Submit the suggestion

Choose Submit suggestion. Give it a title (one line summarising the proposed change - this is what the owner’s review queue shows) and, optionally, a description explaining why the owning organisation should apply it. On submit you land on the profile’s Suggestions tab with your proposal listed as open.
Submitting freezes the draft into the suggestion: the exact spec and inputs at that moment, plus the profile version the draft was seeded from (its base). The draft itself is consumed. A submitted suggestion cannot be edited - to revise one, withdraw it, choose Suggest changes again, and submit anew.

While it is open

  • Your suggestion appears on the profile’s Suggestions tab. On a profile you do not own, the tab shows only your own organisation’s suggestions; the owner sees everyone’s.
  • Withdraw takes an open suggestion out of review - the owning organisation can no longer approve it. Withdrawing still works even if the owner revoked your share grant in the meantime.
  • Each suggestion carries a status: open, approved (with the version it was published as), rejected (with the owner’s note, if they left one), or withdrawn.

If the profile moves on while you edit

The draft’s base is pinned to the version it was seeded from. You can still submit, and the owner’s review flags the drift (see below), but your proposal will not include the newer changes. To start from the newer version instead, discard the draft with Discard draft and choose Suggest changes again - suggestion drafts cannot be rebased.

Keep it as your own copy instead

A suggestion draft can also be published as a profile of your own: Publish as copy creates a brand-new profile in your organisation from the draft, independent of the original. Use it when the owner rejects your change, or when your variant diverges too far to be a suggestion.

Review suggestions on a profile you own

Open the profile’s Suggestions tab. It badges the number of open suggestions, and each row shows the title, status, proposing organisation, and when it was submitted.
1

Expand a suggestion

You get the proposer’s description and the full change list from the suggestion’s base version to the proposal - the same rendering as a version diff, covering structure, manifest settings, and add-on chart versions - plus the raw before/after view.
2

Check for upstream drift

If you have published versions since the suggestion was based, the review warns you: the proposal was based on an older version, and approving publishes the proposed contents as the next version without the newer changes. Approving never merges - it publishes exactly what was frozen at submit.
3

Approve or reject

Approve publishes the frozen contents as the profile’s next version and closes the suggestion in one step - the row then shows which version it was published as. The release notes default to one composed from the suggestion’s title; edit them before confirming if you want the version history to say more. Reject closes the suggestion without publishing; the note you leave is shown to the proposing organisation.
Only the owning organisation can approve or reject, and only the proposing organisation can withdraw. Resolving is first-writer-wins: if a colleague approves or rejects a suggestion while you have it open, your action reports it was already resolved and the list refreshes. Every submit, approve, reject, and withdraw is recorded in the audit log.

Secrets never travel through a suggestion

The suggestion lane applies the same secret handling as publishing a profile version, in both directions:
  • The draft behind Suggest changes is seeded from the published version, which stores secret inputs, never secret values - so the owner’s credentials are not in what you edit.
  • At submit, the payload goes through the same redaction as publish: any secret value in the draft is stripped and declared as a required secret input instead. A suggestion that would still carry a plaintext secret is refused outright, as is a spec carrying a secret placeholder at paths nothing declares as a secret input - so an approved version can never deploy a literal placeholder as a credential.
  • The same checks run again at approve, before the frozen payload becomes a published version.
Whoever instantiates the approved version binds their own secret values at deploy time, exactly as with any other profile version.

Stale drafts and rebase on your own profiles

The owner-side twin of upstream drift: you are editing your own profile in the builder and someone else publishes a new version first. Publishing your draft refuses rather than silently overwriting, and the builder offers the choice:
  • Reset to latest replaces the draft’s contents with the latest published version, discarding your edits.
  • Publish my edits anyway keeps your edits and publishes them as the next version - an explicit decision that your draft supersedes the version published in between, whose changes are not merged in.
Rebasing applies only to drafts editing a profile your organisation owns. A suggestion draft pins its base instead, and its drift is surfaced to the owner at review time.

From the CLI

The same lane is scriptable with the Ankra CLI (v0.13.0 or later); the full flag reference is at ankra stack-profiles.
Reviewing as the owner: