Skip to content

How it connects

One data model, drawn out.

Every block on this site is made of the same handful of records, and this is all of them.

The map

Every record, and every wire between them

12 records across the 8 blocks, and a solid wire is a relation you can open today.

Pick a record. Its connections light up, and the pane says where each one is made.

Teams

Role

A job title with a level and a department. People hold it, and it carries the KRA that role owns.

Connects to

  • A role carries the KRA it owns, and templates it for whoever holds the role.
  • The SOP names its owner, and the Role page carries the KRA that process serves.In build: the role itself owns the process, so the owner resolves from whoever holds it.
  • Kudos is given to a person, and a person holds a role.

Made on the Role page, in Teams.

Sample workspace: Northwind Ops

The reason

One system, not a pile of integrations

  • An integration copies a record. It does not share one.Two tools joined by a connector hold two copies of the same thing and a job that reconciles them. The copy is behind by however long the job takes, and the moment either side is edited by hand the two disagree with nobody being told. Everything on the map above is one record with one id, read by every block that needs it.
  • The connection a stack cannot make is the one you want.A connector can post a message when a task changes. It cannot make the process that produced the task, the role accountable for it and the goal it moves the same objects, because those live in four products that each model them differently. That is the gap the map is drawing, and it is the gap a monthly reconciliation meeting exists to close.
  • So we build the blocks, and connectors when someone needs one.No third party connector ships today, and this page will name one when it does rather than promise a directory of them. What is here instead is the part that cannot be added later: one data model, so a record moves once and every block that reads it is already current.

For whoever signs it off

One model, one place to govern it

If a record exists once, permission on it is decided once.

  • One ladder, then grantsEvery person holds one workspace level. On top of it, a Space, a Folder, a List, a Board or a Doc can be shared directly. A grant only ever adds reach, so the answer to who can open this is the strongest thing the person holds.
  • Scoped visibilityAn admin can narrow what a level sees rather than only widen it, per Space and per object, and assigning someone a task grants them that task so work is never invisible to the person doing it.
  • The logsA security activity log on each account (sign-ins, password changes, sign-out everywhere, live sessions) and an org-wide audit view behind the manager gate.
  • Sign-in hardeningTwo step verification at login, lockout after repeated failures, hashed reset tokens, a password policy, idle session expiry, and a sign-out that actually invalidates the token.

The access page says what we do not have, in the same words.

Or ask

Have it walked through

Book twenty minutes and we will follow one of your own processes from the SOP to the task to the goal, or read the whole Tuesday first.

Open it and follow one.