Spark ERP Docs

Appearance

Command line - move definitions between environments ​

What it is for ​

You built something in a test environment and want it in production, or in a customer's tenant. What you move depends on what it is. This page lists each route and what it carries.

Which route for what ​

You want to moveUseNotes
A whole plugin: pages, forms, entities, rules, workflows, menus, roles, AI assetserp plugin build, then erp plugin publishThe normal route. Installing on a tenant ships everything in the package
AI assets: prompts, RAG pipelines, evaluation sets, knowledge bases, agentserp plugin op ai-bundle-export, then ai-bundle-importOne JSON file. Pass overwrite=true to replace what exists
Engagement: audiences, journeys, contact policyerp plugin op package-export and package-install, or put them in a plugin under metadata/audience, metadata/journey, metadata/contact-policyJourneys arrive as drafts with nobody chosen to run them
Documents: categories, retention policies, document typesThe same package-export and package-install with kinds document-category, retention-policy, document-type, or metadata/<kind>/ in a pluginOnly the structure travels: never cabinets, folders, documents or files. Existing categories and policies are left alone; a type is replaced only with overwrite=true. Needs the manage right on dms.document
Integrations: connectors, flows, connections, queues, syncserp integration export, then erp integration import --applyCredentials never travel. Add each one afterwards
Applications and modulesThe export and import in Studio (an encrypted .erpapp package)Carries pages, forms, themes, dashboards, rules, actions, entities, websites, portals, menus, CMS collections. To add Engagement or Documents definitions, export with ?include=<kind> (repeat for each kind); they install on import without overwriting anything, and the import result lists each one under contributed

Moving Engagement definitions ​

bash
# in the source environment
erp env use test
erp plugin op package-kinds
erp plugin op package-export --kind journey --json '{"codes":["renewal-30"]}' > journey.json

# in the target environment
erp env use prod
erp plugin op package-install --kind audience --json '{"items":[ ... ]}'
erp plugin op package-install --kind journey  --json '{"items":[ ... ]}'

The install answers with one line per item: created, updated, skipped or failed, with warnings. A warning means something the item refers to is missing in the target, such as a message template or a voice agent.

Install audiences before journeys, because a journey names its audience.

Rules that always apply ​

  1. Definitions travel, data does not. People in journeys, runs, call recordings, files, members and orders stay where they were made.
  2. Secrets never travel. Credentials, API keys, storage settings and phone line credentials are set again in the target.
  3. Nothing goes live by itself. Journeys install as drafts. Review anything that changes behaviour, such as a retention policy or a contact policy, before relying on it.
  4. The target's own edits win. An item the target already has is skipped unless you ask to overwrite.
  5. You need the right to manage the thing in the target environment, the same as creating it by hand.

What is not carried yet ​

  • Document-management structure (cabinets, folder trees, categories, retention policies) has no export route yet.
  • The .erpapp application package does not include Engagement items, because they have no application owner.

Where next ​