---
{
  "id": "platform.mindmap.ordering-and-layout",
  "topic": "mindmap",
  "title": "Mindmap ordering anchors and layout",
  "locale": "en",
  "version": "2026-08-09",
  "summary": "Forest ordering uses sibling anchors and server-owned sort keys, while each root anchors an independently laid-out tree.",
  "content": "`move_node` has no public index, position, or `sortKey` input. Place a node with sibling anchors under `newParentId`: `beforeNodeId` means immediately after that sibling, and `afterNodeId` means immediately before that sibling. If both are supplied, those siblings must be adjacent. An anchor outside the target parent’s active children conflicts. Omitting both appends the node to that sibling band. Roots share the null-parent sibling band, so independent-root creation or detach appends there unless anchors are supplied.\n\n`sortKey` is a server-managed, 20-character zero-padded numeric string. When ranks are tight, the server rebalances; response `siblingSortKeys` are authoritative. `get_mindmap` orders nodes by parent, `sortKey`, then creation time.\n\nEach tree is independent. A root’s canvas anchor is its `manualOffset`; non-root offsets are relative. `layoutSide` is `auto`, `left`, or `right` only for the direct children of that tree’s root. `add_node` and create-node APIs accept both layout fields. A deeper create carrying `layoutSide` is invalid. `manualOffset` components must be between -100,000 and 100,000; null clears it. Detach requires the child’s absolute offset and clears its side; attach sends null. Promote-delete Actions cannot supply child anchors, so root children use fallback anchors; only v1 REST accepts them.\n\nReparenting uses a per-Mindmap server lock. On conflict, reread the current forest and anchors before retrying.\n",
  "aliases": [
    "reorder mindmap nodes",
    "sibling anchors",
    "layout side",
    "manual offset",
    "sort key"
  ],
  "tags": [
    "mindmap",
    "ordering",
    "layout",
    "forest"
  ],
  "relatedActions": [
    "arinova.mindmap.get_mindmap",
    "arinova.mindmap.add_node",
    "arinova.mindmap.update_node",
    "arinova.mindmap.move_node",
    "arinova.mindmap.delete_node_promote_children"
  ],
  "relatedActionPrefixes": [],
  "url": "https://docs.arinova.ai/en/kb/mindmap/ordering-and-layout/"
}
---

`move_node` has no public index, position, or `sortKey` input. Place a node with sibling anchors under `newParentId`: `beforeNodeId` means immediately after that sibling, and `afterNodeId` means immediately before that sibling. If both are supplied, those siblings must be adjacent. An anchor outside the target parent’s active children conflicts. Omitting both appends the node to that sibling band. Roots share the null-parent sibling band, so independent-root creation or detach appends there unless anchors are supplied.

`sortKey` is a server-managed, 20-character zero-padded numeric string. When ranks are tight, the server rebalances; response `siblingSortKeys` are authoritative. `get_mindmap` orders nodes by parent, `sortKey`, then creation time.

Each tree is independent. A root’s canvas anchor is its `manualOffset`; non-root offsets are relative. `layoutSide` is `auto`, `left`, or `right` only for the direct children of that tree’s root. `add_node` and create-node APIs accept both layout fields. A deeper create carrying `layoutSide` is invalid. `manualOffset` components must be between -100,000 and 100,000; null clears it. Detach requires the child’s absolute offset and clears its side; attach sends null. Promote-delete Actions cannot supply child anchors, so root children use fallback anchors; only v1 REST accepts them.

Reparenting uses a per-Mindmap server lock. On conflict, reread the current forest and anchors before retrying.