What it does for the analyst: Process Mapper · on a phone: Mobile-Friendly: Process Mapper

A process is a flowchart: steps (boxes of a configurable type), connectors (arrows), and three things that are only there to organise the picture - lanes (horizontal bands), groups (rectangles behind steps) and notes (sticky notes). The editor is one hand-written JavaScript module (PM) on a single page: a sidebar list of processes on the left, the canvas in the middle, a detail panel on the right. It keeps the open process in memory and saves by sending all of it; the server deletes every row and inserts them again, so every save gives everything a new id. There is no versioning and no REST API.

The user page already describes every feature, including the right-click menu and the clipboard, in detail. This page is about how the code is put together.

Seven tables, no tenant_id anywhere and no foreign keys - only indexes on process_id, lane_id and group_id (database/freeitsm.sql, includes/db_verify_indexes.php).

color2 everywhere means "gradient second stop"; NULL is a flat fill (fillStyle() builds the linear-gradient(135deg, ...)).

A lane has no y. Its top is worked out from the lanes above it: recomputeLaneBandTops() sorts by display_order and adds up heights into a cached _bandTop. A group has no lane_id - which lane it is in is worked out from its vertical centre whenever it matters.

get.php?id=N returns data = the processes row plus five arrays, each SELECT * from its table:

{
  "success": true,
  "data": {
    "id": 4, "title": "Incident triage", "description": null, "created_by": 3,
    "created_datetime": "...", "updated_datetime": "...", "is_demo": 0,
    "steps":       [{ "id": 51, "process_id": 4, "type": "decision", "label": "P1?", "description": "",
                      "url": null, "x": 300, "y": 40, "width": 150, "height": 150,
                      "color": "#f59e0b", "color2": null, "lane_id": 7, "group_id": null, "is_demo": 0 }],
    "connectors":  [{ "id": 90, "process_id": 4, "from_step_id": 50, "to_step_id": 51, "label": "", "is_demo": 0 }],
    "groups":      [],
    "lanes":       [{ "id": 7, "process_id": 4, "label": "Service desk", "color": "#f5f7fa",
                      "color2": null, "display_order": 0, "height": 180 }],
    "annotations": []
  }
}

openProcess() maps these into the module arrays steps, connectors, groups, lanes and annotations. Two renames to know: a connector becomes {id, fromId, toId, label} in the browser and goes back as from_step_id / to_step_id; every object also carries its element in el.

Unsaved things get a negative tempId from nextTempId--, and anything that points at them (a connector end, a step's lane_id or group_id) holds that negative number until the save. The lookups all accept either: getStep(id), getGroup(), getLane(), getAnnotation(), and the groupRef() / laneRef() / annotationRef() helpers return id if there is one, else tempId. Selection is the same values: selectedStepIds (a Set), selectedConnectorId, selectedGroupId, selectedLaneId, selectedAnnotationId.

HTML for shapes, SVG for lines. Not a canvas element.

• #pmCanvas (.pm-canvas, tabindex="0") is the scroll container and holds everything. #connectorsSvg inside it holds the connectors; addArrowheadDef() adds the marker.
• renderAll() removes and rebuilds in back-to-front order: lanes (renderLanes()), groups (createGroupEl()), steps (createStepEl()), notes (createAnnotationEl()), then renderConnectors().
• A step is a <div class="pm-step" data-type="<slug>" data-shape="<shape>">. shapeForSlug() looks the slug up in STEP_TYPES_BY_SLUG; the CSS draws the shape. The cloud shape also needs the <clipPath id="pmShapeCloud"> SVG block in index.php. The step gets four .pm-edge-handle dots and, if it has a url, an <a class="pm-step-url-badge">.
• renderConnectors() redraws every connector as a straight line between the facing sides of the two step boxes (calcConnectorPoints(), the larger of the two gaps wins), with a wide hit path and an optional label. Connectors store no geometry, so they follow whatever moved.
• There is no zoom. Coordinates are canvas pixels: mouse position minus the canvas's screen position plus its scroll.

The palette is data, not code:

• process-mapper/index.php queries process_step_types at page load. A type added in Settings appears in the editor only after a reload, because the toolbar and context-menu markup is rendered by PHP.
• stepDims(slug) gives a new step its size from SHAPE_SIZES[shape] and its colour from the type. addStep() and createConnectedStep() both use it.
• changeStepType() swaps the slug, takes the new type's colour and clears the gradient.
• A step whose slug no longer matches a type falls back to FALLBACK_SHAPE ('rounded') and FALLBACK_COLOR. (The comment in delete_step_type.php says "plain rectangle" - the code says rounded.)

The capability and its umbrella Cap::PROCESS_MAPPER_MANAGE are declared in includes/capabilities.php and mapped to the tab in settings/manifest.php. Drawing processes needs plain module access only. See Roles - Developer Guide.

One set of document listeners. bindCanvasEvents() registers a single mousemove and mouseup on the document. onDocMouseMove() and onDocMouseUp() look at which drag state is set and hand over: annotationDragging, then laneDragging, then groupDragging, then dragging (steps), then connectDrag, then rubberBand. Adding a new draggable thing means adding a branch to both.

Keyboard. onCanvasKeyDown() is on the canvas element, not the document, so these only work while the canvas has focus - onStepMouseDown() and onCanvasMouseDown() focus it for that reason: Delete / Backspace, arrow keys (nudge by GRID, 20px), Ctrl+S, Ctrl+A. The sidebar shortcuts (/, Alt+Shift+O, arrows, Enter, Delete on a row) are document-level, in bindProcessListKeys().

There is no undo. Nothing records history.

addConnector() refuses a second connector between the same two steps in either direction. (Network Mapper only refuses the same direction.)

markDirty()  ->  setStatus('unsaved')  ->  scheduleAutosave()   (2s debounce, only if autosave is on)
save()       ->  POST save.php (everything)  ->  openProcess(id, preserveDetail = true)  ->  re-select

• save() sends {id, title, steps, connectors, groups, lanes, annotations}. Each item carries id (or null) and tempId.
• api/process-mapper/save.php runs in one transaction: update or insert the processes row, delete every connector, step, group, lane and note of the process, then insert lanes first (building $laneIdMap), groups ($groupIdMap), steps (translating lane_id / group_id through those maps, building $idMap), connectors (through $idMap) and notes. Each map is keyed by id ?? tempId.
• A connector whose end is not in $idMap is dropped without an error, and so is a lane_id or group_id that maps to nothing.
• Because every id is new, save() first remembers what was selected by position - a step by x, y; a group or note by x, y, width, height; a lane by display_order - and finds it again after the reload. Two steps at exactly the same position would re-select the first.
• scheduleAutosave() waits while any drag is in progress (dragging, groupDragging, laneDragging, connectDrag, rubberBand), because the reload destroys the dragged elements.
• Autosave on / off is the user preference process_mapper_autosave; the sidebar mode is process_mapper_sidebar_mode.
• A new process is created by submitNewProcess() posting save.php with no id and empty arrays.
• get.php and save.php wrap the groups, lanes and notes tables in try / catch, so an install that has not run DB Verify since those shipped still loads and saves the rest.

The open process's id is in the address bar: syncUrl() uses history.pushState only when the URL actually changes, openInitialFromUrl() opens ?id= once the list has loaded, and onPopState() follows back / forward.

All check the session and requireModuleAccessJson('process-mapper'). The write endpoints also call csrfRequireWriteMethod(), on top of the central check in CSRF protection.

• Documents on a process: toggleProcessDocs() mounts the shared documents panel with parentType: 'process' - Attached documents - Developer Guide.
• Demo data: autoLayoutProcessMapper() in api/system/import_demo_data.php lays out demo steps left to right, because the demo JSON has no coordinates - Demo data - Developer Guide.
• Export: captureCanvas() (html2canvas, vendored), exportToPdf() (the picture placed in a PDF by the shared writer, window.FitsmPdf - see PDF writer - Developer Guide), exportToMermaid(). The user page covers what each produces.

• 🔴 TRAP (in the code): e.code, not e.key, for Alt+Shift+O - on a Mac the key types Ø. In bindProcessListKeys().
• 🔴 TRAP (in the code): look for .fitsm-confirm-overlay.active - confirm.js leaves its overlay in the page after the first confirm, so its presence means nothing. In dialogOpen().
• 🔴 TRAP (in the code): esc() must escape quotes. textContent then innerHTML escapes < > & but not " or '; the two extra replaces make it safe inside an attribute (a connector label in value="", the sidebar's aria-label). See Code traps.
• 🔴 Every id changes on every save. Never hold a step, lane or group id across a save.
• ⚠️ delete.php leaves rows behind. It deletes connectors, steps and the process, but not the process's process_lanes, process_groups or process_annotations - and with no foreign keys nothing cascades.
• ⚠️ processes.description is never written by the editor. save.php only sets title; the sidebar hover card shows a description if one is there.
• ⚠️ The Unsaved changes confirm in openProcess() is hard-coded English, not a translation key.
• Processes have no company; anyone with module access sees every process.

• Process Mapper · Mobile-Friendly: Process Mapper
• Network Mapper - Developer Guide - the sister canvas, which copied this one's connector geometry and arrowhead pattern
• Roles - Developer Guide · Database verification - Developer Guide