Book a Demo

Space artifacts (Definitions)

Space artifacts are the set of supporting materials for a space (Workflow) that define the behavior and visual presentation of business processes in the system.

Space artifacts include:

  • Process models (BPMN);
  • User forms (FORM);
  • HTML notification templates (TEMPLATE);
  • HTML signature templates (SIGNATURE).

Important! Only artifact metadata is stored in the definition table (type, key, name, and the link to the space (Workflow)). Artifact content is stored in Attachments .

Key principles

Artifact management is performed in the ⚙️ settings of a space (Workflow) under separate menu items:

  • BPMN diagrams (BPMN) — BPMN diagrams (process models);
  • Forms (FORM) — screen forms for user tasks;
  • Templates (TEMPLATE) — HTML notification templates (Thymeleaf syntax);
  • Signatures (SIGNATURE) — HTML signature templates (Thymeleaf syntax).

Process models (BPMN) and user forms (FORM)

Forms and process models are edited in the built-in modeler based on the bpmn-js library.

Available operations:

  • Name — when a new model is created, the default value is New BPMN (New FORM). It can be changed by the user.
  • Save — save to the internal repository without loading into the process engine.
  • Deploy — (BPMN models only) — publish the model in the process engine. A published process model becomes available for use in the space (Workflow) and in ticket types . If the model contains errors, deployment is not performed.
  • Export — download the model as a *.bpmn file.
  • Import — import the model from a *.bpmn file.

When modeling a process, follow the requirements of BPMN 2.0 notation and best practices .

To bind a form to a user task, set the form type to Camunda Forms and specify the form key (Form key) as the form reference (Form reference).

In Camunda 8 the form reference is stored in the model as formId, and on deployment Zeebe replaces it with the numeric key of the deployed form. Cabinee restores the original formId from the process model, so the form key in space artifacts must match the form identifier in BPMN.

Requirements for Camunda 8 models

Three requirements without which a deployed model will not work with Cabinee.

Execution platform. In the diagram properties, Camunda Cloud (Camunda 8) must be selected. Models saved for another execution platform use a different extension namespace and will not deploy.

The modeler built into Cabinee uses the legacy properties panel (camunda-bpmn-moddle) and can neither show nor save zeebe: extensions. Prepare Camunda 8 models in Camunda Modeler and load them into the space via Import; the embedded editor remains suitable for viewing and for edits that do not touch zeebe: blocks.

Correlation key on message events. Cabinee sends ticket actions to the engine as messages. Correlation uses the correlationKey value computed from an expression in the model. Therefore every message event must declare the correlation key as the businessKey variable:

<bpmn:message id="Message_approve" name="approve">
  <bpmn:extensionElements>
    <zeebe:subscription correlationKey="=businessKey" />
  </bpmn:extensionElements>
</bpmn:message>

If the correlation key is missing or points to another variable, the message will not reach the instance: the engine responds that there is no subscription, and the ticket action silently does not take effect.

Service tasks. Described with zeebe:taskDefinition and zeebe:taskHeaders; see External tasks .

Deploying models to Camunda 8

The Deploy button still uses the legacy publication path and is not yet wired to the orchestration cluster. Deploy models to the cluster with external tools: Camunda Modeler, zbctl, or a CI deployment step.

After deployment, the model must be available to the cluster, and its bpmnProcessId must be set as the process key of the space or in the ticket type . Cabinee reads the list of deployed definitions via /v2/process-definitions/search, so the process-key dropdown shows only processes already present in the cluster.

The internal artifact repository works as before: models are stored and versioned in Cabinee; publication to the engine is performed separately.

Signatures (SIGNATURE)

Signature templates are stored in HTML format. Dynamic rendering uses the Thymeleaf templating engine. Template variables can use objects of the Ticket , Workflow , and User (the current user) classes.

Example signature template:

<div style="font-family: Arial, sans-serif; font-size: 14px; color: #333;">
    <p>Sincerely,</p>
    <p><strong th:text="${user.firstName} + ' ' + ${user.lastName}">First Name Last Name</strong></p>
    <p>Reunico Team</p>
    <p>E-mail: <a href="mailto:info@reunico.com">info@reunico.com</a></p>
    <p>WWW: <a href="https://reunico.com">https://reunico.com</a></p>
</div>