Provisioning makes a template or skill built in one organisation available in another, so you don't need to rebuild it by hand. You create the content once in the source organisation, and provisioning copies it to the organisations that need it.

There are two ways content moves between organisations.

Both methods follow the same process. The Copy method checks more before it runs. For details, see Known limitations.

Only organisation templates and organisation skills can be provisioned. Personal templates and personal skills stay with the user who created them.

You can provision two kinds of content:

Apps aren't provisioned directly. An app is a publishing layer that a Researcher admin builds around a template in each organisation. It places the template in a Navigator surface, such as a Quick Panel, Quick Action or Quick Section, and publishes it to users.

When the template arrives in a target organisation, an App Author or App Publisher there can wrap it in an app and publish it. The app's own settings, including surface type, panel size, mobile deployment, feature toggles and audience, are chosen in each organisation and don't travel.

A template has several parts, and each part travels differently.

Skills attached to the template travel with it. MCP server configuration travels too, but secrets are removed, so you need to enter them again in the target organisation.

You can provision skills on their own. The skill's name, description and instruction text travel, along with all of its files, including the main skill file and every supporting file.

With Distribute, target organisations get access to a single shared copy of the skill's files, so the files aren't duplicated in each organisation. With Copy, the skill is duplicated into the target organisation.

Check these before you provision a template or skill. If a requirement is missing, provisioning is refused before it starts. The one exception is connector access on Distribute, which is covered under Known limitations.

Assistants and connectors reach organisations through Evo Foundry. A template that attaches an assistant or uses connectors only works once they're in place in the target organisation.

An assistant package includes the assistant's name, description, instructions, model settings, products, Quick Actions, skills and sub-assistants. It doesn't include endpoints, headers or credentials. The connectors, Quick Actions and sub-assistants the assistant uses must already exist in the target organisation.

A connector package includes the AI and coding instructions, skills, static tools, workflow nodes and operation details that you author in Access Evo Researcher. It doesn't include the base registration, endpoints, base URLs or credentials. These are set up separately for each environment.

Once an organisation receives any Foundry distribution, it sees only the connectors distributed to it. A connector that a template relies on must be distributed to the target organisation in its own right.

Some checks are stricter on the Copy method than on Distribute.

Action dependencies on other actions aren't resolved automatically yet. On Distribute, access to an action's UI component is checked only at environment level.

Only a reference travels for Knowledge and Data, and the contents stay in external services. A reference can therefore point to content that doesn't exist in the target environment. Provisioning is refused if the whole capability is unavailable, but individual references aren't checked one by one. Review these references in the target organisation after provisioning.