Template permissions and visibility

Templates belong to an organization. Visibility defines who can find a resource in the catalog; permissions define which actions each person can perform. Together, these rules keep organization boundaries clear while allowing collaboration without shared accounts.

Available actions

The resource actions are:

There is no separate deploy permission. Deployment uses project.create and, for a private template, also requires template read access. This keeps project creation under the same rule used by other console flows.

Owner, assistant, and member

The organization owner has full administrative access. Assistants and members depend on explicit grants or linked organization policies. A non-owner creator receives the specific grants needed to manage the template they created; this does not automatically grant access to every template.

To create, grant template.create at organization scope. To update, publish, or delete an existing template, grant the matching action on that template. To let a collaborator only view a private template, grant template.read without including change actions.

Private templates

A private template is limited to its owning organization. The person must be in the same organization and have template.read to open details or start a deployment. Switching the active organization changes the private templates available in the console.

Knowing a template identifier does not bypass organization and permission checks. The catalog and API apply the same isolation rules to listing, detail, and deployment.

Public templates

When the owner or an authorized person publishes a template, it appears in the public catalog for authenticated members of other organizations. Publication shares the name, summary, description, tags, public name of the author organization, revision, application, port, persistence, expected variables, and prepared defaults. The author organization identifier is not shared.

Publication does not share projects, data, credentials, grants, or contracted capacity from the author organization. owned_by_current_organization only tells the client whether the Template belongs to the active organization; authorization is still enforced by the API. A public template can also appear in the public row for its author organization; administrative actions remain visible only to people with the matching grants.

Good practices

• use a specific policy for authors who need to create and review templates;
• keep template.publish restricted to people who review public content;
• grant project.create only to people who can start billing and capacity;
• avoid sensitive values in descriptions, tags, and references;
• review members and policies when someone changes role;
• remove old templates without deleting projects already created from them.

Next steps

• Create and publish a template
• Deploy an application from a template
• Manage organization members and permissions
• Read the API reference