authzed. How a CRM writes to SpiceDB ← All demos

How a CRM writes permissions into SpiceDB

The CRM saves its own record, then sends SpiceDB the relationship that changed. Run the six steps.

    The CRM app saves to its own database, writes relationships to SpiceDB, and SpiceDB stores them in its datastore. Other services ask SpiceDB permission questions. CRM userclicks in the browser CRM app serveryour application code CRM databaseaccounts, deals, teams SpiceDBpermission service SpiceDB datastorePostgres Other servicesreports, API, search WriteRelationships ZedToken back CheckPermission save record 1 2 3 4 5 6
    1 Someone acts in the CRM 2 The CRM saves its record 3 It sends the relationship to SpiceDB 4 SpiceDB stores it 5 A ZedToken comes back 6 Anyone can now ask a permission question

    Nothing has happened yet

    The CRM is empty and SpiceDB knows no relationships, so nobody can see anything. Run step 1 to create the first account.

    6

    Who can do what right now

    CheckPermission for every person
    2

    The CRM saves its record

    -- nothing yet
    3

    It sends SpiceDB the relationship

    POST /v1/relationships/write
    // nothing yet
    // SpiceDB's reply appears here
    4

    SpiceDB stores it

    relation_tuple table, Postgres

    Crossed-out rows are deletes: stamped with deleted_xid, garbage-collected later. ... means the subject itself.

    Write what changed, not everything

    The CRM only sends a relationship when one changes: an owner, a team member, a share. Access to new deals comes for free, because the deal points at its account.

    One request, all or nothing

    Several updates in one WriteRelationships call land in a single transaction. In step 6 the old owner is removed and the new one added together, so there is never a moment with two owners or none.

    Keep the ZedToken

    The reply includes a ZedToken. Store it with the record. A later check that passes it is guaranteed to see this write, even if caches haven’t caught up.

    Save first, then write

    Commit the CRM record, then call SpiceDB. If that call fails, retry it: TOUCH is safe to repeat. Larger systems put the update in an outbox table and let a worker send it.

    The schema behind it

    Written once. It tells SpiceDB how the relationships combine into permissions.

    definition user {}

definition team {
    relation member: user
}

definition account {
    relation owner: user
    relation team: team

    permission edit = owner
    permission view = edit + team->member     // the owner, plus everyone on the account's team
}

definition deal {
    relation account: account
    relation viewer: user

    permission edit = account->edit              // whoever can edit the account
    permission view = viewer + account->view      // people it was shared with, plus the account's viewers
}

    ZedTokens and transaction IDs here are illustrative; real values are opaque and longer. The request uses SpiceDB’s HTTP API; the gRPC API and client libraries send the same fields.