Access Matrix

Access Matrix helps a business define what each role should be able to see and change. It starts with the smallest useful setup and a short recommendation, then builds artifacts when requested. The proposed operating sequence moves from a role list and system inventory to access rows, quarterly review, and removal of obsolete access. The matrix stays in a tool the team already uses for review.

The workflow distinguishes setup, conversion, review, and advice requests before asking questions. It gathers only missing facts that would change the result, one question at a time. Relevant context includes systems or data in scope, role count, external participants, owner and administrator roles, manager responsibilities, view versus edit permissions, confidential areas, review frequency, current tracking gaps, and the intended output. Unknowns remain unknown rather than becoming invented assumptions.

The shared field reference defines module identity, organizational layer and SME tier, permission descriptions for each role, and confidentiality. Role columns cover owner or CEO, board, finance, tax, HR, IT and administration, department heads, line managers, employees, interns, and clients. Free-text permission cells record the expected access for those roles. SME tier and confidentiality use select fields; the register supplies tier choices from Micro through Enterprise and confidentiality choices from Public through Highly Restricted.

Use it for role-permission questions, access-control spreadsheets, or a process that currently lives in documents or inboxes. A review request receives a check of the shared material rather than an unsolicited rebuild. An advice request receives a recommendation with an offer to produce relevant artifacts. This example captures the intended question:

We have 6 roles and want to know who can see payroll and bank details.

The skill does not compute payroll, file taxes, give legal advice, or provision and revoke access. It has no automation, reminders, or sync; those require an integration layer. Real decisions still need appropriate legal, tax, or HR review.

Confirmed business context determines the fields and requested formats. CSV, SQL DDL, JSON Schema, Notion mapping, or an explicitly requested workbook are derived from the same list. Templates are empty unless synthetic examples are requested. Real names, salaries, medical information, and banking data are excluded from generated rows.

Excel-compatible CSV uses UTF-8 with a byte order mark and identifies columns needing formatting. A CSV is distinct from an XLSX workbook. Display labels remain aligned across CSV and JSON, while normalized SQL identifiers are documented. The SQL schema adds creation and update timestamps.

Notion output goes through notion-manual-import for the CSV, property mapping, import steps, and verification. Manual mappings require no connection; a live workspace change requires verified access and an authorized target. Imported IDs remain text, and select properties are configured after import. The skill records a plan and templates without claiming an unperformed live workspace build.