Workspace hierarchy

Factorial Code supports workspace inheritance. A child workspace inherits all modules, processes, team variables, locales and dependencies from its parent as read-only resources — they can be imported, scheduled, and triggered by webhooks without copying any code, and inherited variables and packages are available to every execution.

base-app  (parent)
      └── prod-{appId}  (child — inherits base-app)
                └── deploy-{deployId}  (grandchild — per customer; no code, just variables and executions)

Each shared workspace comes in a JavaScript and a Python variant; your App inherits the one matching its language — see Sample apps & foundation.

Base workspace — `base-app`

Everything in base-app is available to every App workspace via fcode.import(...). You never copy this code — it travels automatically through inheritance. It includes the FactorialClient and shared utilities such as fc-utils, checkWebhookChallenge, and setupWebhook. Integration Apps additionally inherit base-integration-app. See Sample apps & foundation for what each workspace provides.

Shared variables

Variables follow the same hierarchy: a workspace uses the variables defined in any of its parents without redefining them. Defining a variable with the same key in the child overrides the inherited one for that workspace — the child’s value is what its executions see, and the parent’s entry disappears from the child’s list. So an App can keep its defaults in prod-{appId} and let each deploy-{deployId} override only what differs per customer.

Inherited variables are read-only where they are inherited: edit or delete them in the workspace that owns them, or override them locally. See Using Team Variables for the details.

Shared dependencies

Dependencies follow the same hierarchy, merged per package name: a workspace installs its parents’ packages alongside its own, and declaring the same package name locally overrides the inherited version. So base-app can pin the packages every App needs and an individual App only declares what it adds — or the one version it needs to differ on.

Workspace types

dev-{appId} — your development workspace. Clone it locally, build and test here. Requesting a release publishes a workspace version here, snapshotting every process and module under the release tag.
prod-{appId} — the promoted, production version of your App. Created when the first release is requested. Promotion copies the released workspace version into it and points the stable alias at that version, which is what customer workspaces follow. Treat it as read-only: changes belong in dev-{appId} and reach production through a release, not by editing here. Only operators and the App’s Factorial team admins can write to it at all — see Roles & permissions.
deploy-{deployId} — a per-customer workspace. It carries no code, only the customer’s own variables (credentials, mappings) and executions, inheriting base-app, base-integration-app, and prod-{appId} — including their variables, so it only defines the values that are specific to that customer.