Build across multiple orgs as a partner

A merchant administrator works in one store. A partner works across many, often several orgs in a day, each at a different stage and on a different sandbox. That difference is what usually decides which tooling a partner reaches for.

Two routes, and what each suits

The StoreConnect MCP connects an agent to one specific store. It stages changes for review before they go live, and the agent works within the permissions of the StoreConnect user it signs in as. That scoping is a feature when the job is to build or restyle a particular storefront, and it is the safer of the two because nothing reaches the store without approval. It requires StoreConnect v22 or later. See Build on StoreConnect using AI agents.

The Salesforce CLI authenticates per org and is not tied to a store. It reaches anything in the org that the authenticated user can see, including the areas the MCP does not cover. Point-of-sale configuration is one of those: POS layouts, views, action groups, action items, and print templates are Salesforce records, and the CLI is how an agent or a developer works with them. See Build POS with an AI agent.

Most partner work ends up on the CLI, because a partner is rarely working in one store at a time and often needs the parts of the org the store-scoped route does not reach.

What changes when you use the CLI

The trade for that reach is that the guardrails are yours to provide.

• A CLI write is immediate. There is no staging step and no approval prompt. What is written is live when it is written.
• Nothing scopes it to a store for you. Some StoreConnect configuration is org-wide rather than per store, so a change can travel further than intended. Every POS configuration object works this way.
• The target org is a flag, not a session. Alias every org, and confirm which one you are pointed at before a write rather than after.

Work in a sandbox, review what was produced, and move the result deliberately. See Move data from sandbox to production.

The AI skills work either way

The StoreConnect AI skills are knowledge rather than access, and are useful with nothing connected at all. They teach an agent StoreConnect’s Liquid, its record conventions, and its object model, which is what keeps it from writing plausible Salesforce that StoreConnect does not accept. Install them whichever route you take. See Install the StoreConnect AI skills.

The published references are the rest of the agent’s map: the object references for the records, the Liquid references for what a template can do, and the POS actions reference for what a POS action takes.

Scope the agent with its own integration user

Because a CLI write is immediate, the authenticated user’s permissions are the guardrail. Where the MCP route puts an approval step between an agent and the store, the CLI route has the Salesforce permission model and nothing else. That makes the choice of user the most important decision in the setup.

Give the agent its own user rather than letting it act as yours. Salesforce provides an integration user for exactly this purpose, with API-only access and its own license type, and it limits what a mistake or a stolen credential can reach, in three ways at once. See Salesforce’s integration user documentation for the current entitlements and setup steps.

• It cannot sign in to the Salesforce UI. The credential is usable only through the API, so it is worth much less to anyone who obtains it, and it cannot be used to browse the org.
• Its permissions are the ceiling. Grant only the objects and fields the work needs. An engagement building a register needs the POS configuration objects and the catalog it reads; it does not need customer records, orders, or payment data. Anything outside that grant is not reachable, whatever the agent is asked to do.
• Actions are attributable and revocable. Every record the agent creates or changes carries that user, so the audit trail separates its work from a person’s, and access ends with one switch when the engagement does.

Create one per org you work in, scope it to the task, and deactivate it when the work finishes. Treat its credential the way you would any production secret: out of templates, out of shell history, and out of anything that syncs to a device.

Build so the work moves between orgs

A partner builds the same pattern repeatedly, so the value is in configuration that can be lifted into the next org without editing.

• Address things by name. Identifiers, API names, product codes, and store variable keys are identical in every org. Salesforce IDs are not.
• Keep environment-specific values, such as endpoints, outlet identifiers, and register codes, in Store Variables rather than in templates.
• Deploy custom objects and fields as metadata before loading any record that names them.
• Keep the export and load order in version control, so the second delivery is a repeat rather than a rediscovery.

Deploy POS configuration to production works through these in detail for point of sale, and the same habits apply to the rest of a build.