3 min read

Access in MindFront is governed by Teams. A team is a named group of users — HR, FINANCE, SALES, IT, EXEC — and every resource that contains information (memories, conversations, documents, drafts, reports) is tagged with the teams allowed to see it.

A user can see a resource if any of three things is true:

  1. They are the originator of the resource — the human it was created for, or the human who created it.
  2. They are explicitly added to the resource (e.g. added to a conversation).
  3. They share at least one team with the resource’s tagged teams.

This is OR-semantics: one match anywhere is enough.

When MindFront acts on behalf of a user, it inherits that user’s team membership — it can only act on resources the user is permitted to see.

Two built-in teams

TeamMembership
EveryoneEvery user in the org belongs. Membership is mandatory — there’s no way to remove a user from it. Use it to tag anything the whole org should see.
AdminOperators of the system. Created at install; users are added by other admins. The Admin team is a normal team grant, not a god-mode bypass. Admins only see resources actually tagged with Admin (or shared via team overlap / explicit add). Personal resources stay personal.

The other teams in your deployment — HR, FINANCE, etc. — are whatever your administrator creates to match the access boundaries that already exist in your organization.

Example

%%{init: {'flowchart': {'defaultRenderer': 'elk'}}}%%
flowchart LR
    %% Users
    Alice((Alice
Everyone + HR + FINANCE))
    Bob((Bob
Everyone + SALES + IT))
    Carol((Carol
Everyone + EXEC + HR +
FINANCE + SALES))
    Admin((Admin
Everyone + ADMIN))

    %% Resources
    HRM[HR Memories
tagged: HR]
    FINM[Finance Memories
tagged: FINANCE]
    SALESM[Sales Memories
tagged: SALES]
    ITM[IT Memories
tagged: IT]
    EXECM[Executive Memories
tagged: EXEC]
    PRIV[Alice's Personal Notes
no teams, originator: Alice]

    Alice --"HR"--> HRM
    Alice --"FINANCE"--> FINM

    Bob --"SALES"--> SALESM
    Bob --"IT"--> ITM

    Carol =="EXEC"==> EXECM
    Carol =="HR"==> HRM
    Carol =="FINANCE"==> FINM
    Carol =="SALES"==> SALESM

    Admin -."ADMIN".-> HRM
    Admin -.->|"no team overlap"| PRIV

    Alice --"originator"--> PRIV

    style Alice fill:#f9f,stroke:#333
    style Bob fill:#bbf,stroke:#333
    style Carol fill:#fcf,stroke:#333
    style Admin fill:#ffa,stroke:#333

    style PRIV fill:#ddd,stroke:#999

Note the Admin user in this example sees the HR/Finance/Sales/IT/Exec memories only because those memories are also tagged with the Admin team. Tag a memory exclusively with HR and even an admin won’t see it without HR membership. Alice’s personal notes have no team tags at all — only Alice (the originator) sees them, full stop.

Access table

Required to access
Another user’s resourceAt least one team in common with the resource’s tagged teams, OR you are added to it.
A memoryAt least one team in common with the memory’s tagged teams.
A conversationYou are the originator, an added user, or in one of its teams.
A draft / approvalSame as the conversation it belongs to.

How team membership works

Teams are created and assigned by your administrator. When a user joins the organization, the administrator adds them to the teams that match their role — HR for HR staff, FINANCE for finance staff, and so on. Adjusting access later is a matter of changing team membership, not relabelling every resource.

Ask your administrator to create new teams, change membership, or grant access at any time.