{"slug":"architecture/WORKBENCH_ROLE_CAPABILITY_MAP","title":"IntegrateWise Workbench Role–Capability Map","section":"architecture","sectionLabel":"Architecture","status":"unclassified","type":"document","path":"architecture/WORKBENCH_ROLE_CAPABILITY_MAP.mdx","bytes":10197,"description":null,"updated":null,"source":"integratewise/Integratewise-docs-wiki","content":"\n**Status:** Canonical mapping reference; runtime access remains RBAC- and\npolicy-resolved\n\n**Date:** 2026-07-28\n\n**Code authority:** `packages/workbench-config/src/roles.ts`\n\n**Source support:** `IntegrateWise_Role_Workbench_Mapping_Package.zip`\n\n## 1. Mapping law\n\nA role configuration is a projection recipe, not a separate schema and not an\nauthorization token.\n\n```text\ntenant membership\n× effective RBAC\n× role\n× department\n× industry\n× enabled connectors and entity availability\n× policy and entitlement\n× active context\n→ permitted Workbench projection\n→ permitted semantic capabilities\n```\n\nThe Gateway resolves the effective projection. The browser does not choose its\nown authority. Canonical Spine records keep the same identity regardless of\nwhich role views them.\n\nConnector names in a role configuration are discovery/availability candidates.\nThey do not require a customer to use a particular vendor, prove that a\nconnection is active, or permit the Product to call the provider directly.\n\n## 2. Shared Platform projection\n\nAll 12 roles receive the following Platform modules when RBAC and policy allow:\n\n| Module ID | Product label | Responsibility |\n| ---------------- | --------------------- | ------------------------------------------------------------------ |\n| `integrations` | Integration Manager | Connector catalog, connections, sync, webhooks and schema mappings |\n| `configuration` | Configuration Manager | Projection inputs, tenant policies and configuration |\n| `activation` | Activation Hub | Onboarding and operational-readiness state |\n| `governance` | Governance | Approvals, policy decisions and audit |\n| `continuity` | Continuity | Governed context and memory projection |\n| `network-graphs` | Network Graphs | Entity and relationship projections from the Spine |\n\nThe Twin is not a shared Platform module or permanent sidebar destination. It\nis a contextual Workbench capability governed by the Silence Law and the Four\nButtons.\n\n## 3. Role projection registry\n\nThe table records the current repository configuration. Module and capability\nnames are semantic identifiers; Product labels may be friendlier while\npreserving the same contract.\n\n| Role ID | Projection | Default RBAC profile | Role-specific operational modules | Principal entity/capability families |\n| --------------------- | ----------- | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `founder` | `founder` | `admin` | Home, accounts, contacts, meetings, docs, tasks, calendar, risks, expansion, analytics, pipeline, knowledge, projects, notes, team, operations, admin, settings, profile | `entity360.*`, connections, sync, tasks, analytics, knowledge, pipeline, signals, projects, calendar, docs, meetings, admin, billing, connectors, webhooks, schemas |\n| `customer-success` | `cs` | `business-ops` | Home, accounts, contacts, meetings, docs, tasks, calendar, risks, expansion, analytics | Account/contact 360, connections, sync, tasks, analytics, knowledge, calendar, docs, meetings, signals |\n| `sales` | `sales` | `sales` | Home, pipeline, accounts, contacts, meetings, tasks, calendar, docs, analytics | Account/contact/deal 360, pipeline, connections, sync, tasks, analytics, calendar, docs, meetings |\n| `support` | `support` | `business-ops` | Home, accounts, contacts, tasks, calendar, knowledge, analytics | Account/contact/ticket 360, connections, sync, tasks, analytics, knowledge, calendar |\n| `project-management` | `pm` | `business-ops` | Home, projects, tasks, docs, meetings, calendar, knowledge, analytics | Project/task 360, projects, tasks, connections, sync, analytics, knowledge, calendar, docs, meetings |\n| `marketing` | `marketing` | `business-ops` | Home, analytics, contacts, docs, calendar | Campaign/contact 360, connections, sync, analytics, knowledge, calendar, docs |\n| `business-operations` | `bizops` | `business-ops` | Home, projects, accounts, contacts, meetings, docs, tasks, calendar, notes, knowledge, team, pipeline, risks, expansion, analytics | `entity360.*`, connections, sync, tasks, analytics, knowledge, pipeline, signals, projects, calendar, docs, meetings |\n| `technology` | `tech` | `business-ops` | Home, projects, tasks, docs, knowledge, analytics | Project/task 360, projects, tasks, connections, sync, analytics, knowledge, docs |\n| `human-resources` | `hr` | `business-ops` | Home, team, tasks, docs, meetings, analytics | Employee/project 360, connections, sync, tasks, analytics, knowledge, calendar, docs, meetings |\n| `finance` | `finance` | `business-ops` | Home, accounts, docs, analytics | Account/invoice/subscription 360, connections, sync, analytics, knowledge, docs |\n| `legal` | `legal` | `business-ops` | Home, docs, tasks, analytics | Contract 360, connections, sync, tasks, analytics, knowledge, docs |\n| `personal` | `personal` | `developer` | Tasks, calendar, notes, knowledge | Tasks, calendar, knowledge, connections |\n\n## 4. Mapping-package interpretation\n\nThe supplied role package contains one master workbook and 12 role workbooks.\nIts entity catalogs, click-context maps, CRUD tables, canvas/page definitions,\nbackend mappings, governance rules and acceptance tests are detailed projection\nrequirements. They do not independently:\n\n- create physical per-role or per-tenant schemas;\n- authorize a capability;\n- prove a connector is operational;\n- allow Loader or Triage to write canonical truth;\n- make every record click open the Twin; or\n- override the repository's hyphenated role IDs.\n\nWorkbook role IDs that use underscores must be normalized to the repository\nIDs, such as `customer_success → customer-success` and\n`project_management → project-management`, before contract generation.\n\n## 5. Runtime response\n\nDiscovery and projection responses must expose the resolved result, not the\nentire configuration registry:\n\n```ts\ninterface ResolvedRoleProjection {\n role: string;\n projection: string;\n modules: Array<{\n id: string;\n label: string;\n state: \"available\" | \"degraded\" | \"unavailable\" | \"forbidden\";\n }>;\n capabilities: Array<{\n id: string;\n mode: \"read\" | \"propose\" | \"approve\" | \"execute\";\n }>;\n connectorAvailability: Array<{\n connectorId: string;\n state: \"available\" | \"authenticated\" | \"operational\" | \"degraded\";\n }>;\n}\n```\n\nExecution still requires a governed command and, where applicable, a valid\napproval token. A visible module or capability never grants write authority by\nitself.\n\n## 6. Acceptance\n\n- All 12 repository role IDs resolve without underscore/hyphen ambiguity.\n- Shared Platform modules are independently permissioned.\n- Role/department/industry changes alter projections, not canonical schema.\n- Disabled or disconnected connectors reduce availability without creating\n broken routes or synthetic data.\n- The Product receives semantic projection responses through Gateway only.\n- Twin visibility follows explicit Ask/Assign or a qualified material signal.\n- CRUD commands pass tenant, RBAC, policy, provenance and governed-writer\n checks before a canonical mutation.\n"}