Skip to content

Packages

Packages (/packages) are the mechanism for moving a finished configuration between Orbita installations: a package bundles entities and everything built around them into a single file that can be exported, transferred, installed on another system — or used to upgrade it to a newer version.

Typical scenarios:

  • moving a configured solution from staging to production;
  • replicating one solution across several installations (e.g. an integrator's clients);
  • versioning: you release package v1.1.0 with a new field and process — client systems upgrade by importing it without losing their data;
  • built-in presets (Service Desk, CRM, HR, Project Management) are the same packages shipped with the distribution.

The section is available to administrators and holders of the admin.entities section permission ("Entity constructor & packages").

What a package contains

A bundle includes the selected entities and the objects attached to them:

SectionWhat is transferred
EntitiesField structure, forms, state models, automations
RelationsRelations between package entities
RolesRoles with CRUD permissions and record access rules
DashboardsDashboards and charts over the package entities
ProcessesBPMN process templates
PortalsSelf-service portals with their pages
Notification templatesConfigured email/notification templates
ReportsReport definitions
MenuMenu items for the package entities

Data (the records themselves) is not part of a package — configuration is what travels. To move records use the Migration tab in Settings or the REST API.

Working with packages

Creating a package

  1. Open PackagesCreate package
  2. Set the name, slug and version (semver, e.g. 1.0.0)
  3. Assign entities to the package — related objects (roles, processes, dashboards, portals, reports) are picked up automatically at export time

An entity can belong to only one package; assignment is managed on the package page.

Export

The export button on the package page downloads a JSON bundle (format orbita_package_bundle, format version 2). The file is self-contained: it can live in git and travel between installations.

Import and preview

  1. PackagesImport
  2. Pick a bundle file — the system shows a preview: contents by section and the version verdict
  3. Confirm the installation

Preview verdicts:

SituationBehaviour
Package not installedNormal installation
The file is newer than the installed versionUpgrade: "Upgrade from v{from} to v{to}. User customizations are preserved (merge)"
Same versionRe-import repairs anything missing
The file is older than the installed versionDowngrade warning; requires explicit "I understand, downgrade anyway"

Conflict strategies

When an object from the package already exists in the system, the chosen strategy applies:

  • merge (default) — new fields/objects are added, user customizations survive;
  • skip — existing objects are untouched, only missing ones are added;
  • replace — objects are reset to the package state.

After installation a deploy report is shown: what was created, updated, left unchanged, and warnings (e.g. objects skipped due to conflicts).

Built-in packages

The Built-in packages block lists the presets shipped with the distribution (Service Desk, CRM, HR, …) with their versions. An uninstalled package shows Install; an installed one with a newer version available shows Update. This is the same mechanism as the onboarding wizard: presets chosen during onboarding appear here as installed packages.

Example: shipping a solution update

An integrator maintains a "Procurement requests" solution (package procurement v1.0.0) at a client and needs to add a "Budget line" field and a finance-approval step:

  1. On the staging system the integrator modifies the entity and the process
  2. On the package page bumps the version to 1.1.0 and exports the bundle
  3. At the client: Packages → Import; the preview says "Upgrade from v1.0.0 to v1.1.0"
  4. After confirmation the new field and process step appear in the client system; the client's local customizations (their automations, their roles) survive thanks to the merge strategy

See also

Orbita ITSM documentation