# Create Vitruvio Process BPMN > All messages shown to the user must be written in Portuguese. You are creating the **BPMN workflow file** of a Vitruvio process. This skill is focused on the `.bpmn` file only — the desktop form is handled by **vitruvio-criar-form-desktop** (process variant) and the mobile form by **vitruvio-criar-form-mobile** (process variant). ## Step 1 — Confirm you are inside a Vitruvio repo ```bash ls vitruvio.json 2>/dev/null && echo "OK" || echo "NOT_A_VITRUVIO_REPO" ``` If `NOT_A_VITRUVIO_REPO`, stop and tell the user to `cd` into the correct repo. ## Step 2 — Collect flow details Ask the user (in a single message, only ask what is missing): - **Key** — snake_case or camelCase unique identifier. Becomes the BPMN process ID and the folder name. Must match the `key` used for the process in `vitruvio.json`. - **Name** — human-readable label. - **Who can start it?** — group key(s) allowed to open the process (e.g. `gestao`, `admin`). Used in `activiti:candidateStarterGroups`. - **Steps** — the human tasks (user tasks), and which group handles each. A simple linear flow is enough to start. - **Decisions / branches?** — any exclusive gateways with conditions. - **Automatic steps?** — any script tasks running between user tasks. ## Step 3 — Write the BPMN file: `processes//.bpmn` ### Critical rules - The `` value is the canonical process identity. The importer reads it from the BPMN, not from vitruvio.json. **It must match the `key`.** - Every node must appear in a `` / `` **and** in the `` section — Vitruvio renders the diagram. - Each `activiti:formKey` on the start event and user tasks must match a `
` in the desktop form XML (and mobile form, if present). - Process variables from submitted forms are auto-named `{formKey}_{fieldId}` (e.g. `formAbertura_status`). Gateway conditions reference them. - Gateway conditions use `#{variable == 'value'}` (JUEL expression language). - Script tasks call `vScriptService.loadScript('scriptKey', 'javascript')`, **not** `libService`. ### Minimal skeleton (start → user task → end, single lane) ```xml inicio task_executar fim flow_inicio_task flow_inicio_task flow_task_fim flow_task_fim ``` ### Multi-lane pattern (when tasks belong to different roles) Add each lane inside ``, list the node IDs inside each lane, and adjust the BPMNDi bounds: ```xml inicio fim task_executar ``` ### Script task — script side ```javascript // In inside a scriptTask: var f = vScriptService.loadScript('meu_script', 'javascript'); f(execution); // In the script file itself (pattern: process/task script — see vitruvio-criar-script): (function(execution) { var db = libService.loadScript('db'); var banco = new db(db.VITRUVIO_DATASOURCE); var status = execution.getVariable('formAbertura_status'); // ... })(execution) ``` ## Step 4 — Manifest If this skill is run **standalone** (the process already exists in `vitruvio.json`), ensure its entry has `"bpmn": "processes//.bpmn"`. Do not create or modify the rest of the entry here — full registration is handled by **vitruvio-criar-processo**. ## Step 5 — Report Tell the user: - File created/updated: `processes//.bpmn` - The process identity is the `` — it must match the key. - Each `activiti:formKey` must have a matching `` in the form XML (create/update it with **vitruvio-criar-form-desktop** / **vitruvio-criar-form-mobile**). - Submitted field `id="X"` in `formKey="formAbertura"` becomes variable `formAbertura_X`. - For complex flows, recommend editing the BPMN in bpmn.io or Camunda Modeler before deploying.