Platform overview

Tessule is a CRM where you define the data model: instead of fixed Contacts and Deals objects, you build tables with exactly the fields your process needs, then layer views, permissions, automation and analytics on top. This page is the map — what each concept is, where it lives, and which guide covers it in depth. Five minutes here should tell you where to go for everything else.

If you only remember one thing: there are two boundaries. The organization is the management boundary — people, billing, security policy, backups. The workspace is the data boundary — schema, records, roles, automation. Nothing in a workspace is visible from outside it, not even to organization owners.

The containment hierarchy (left) and the systems that attach at each level (right). Organization-level systems govern people and money; workspace-level systems govern data and process.

Organizations → workspaces → tables → fields → records

The containment hierarchy, top to bottom:

Level	What it is	What lives here
Organization	The management grouping. A new account creates or joins one during onboarding.	Members and invitations, org roles (owner / admin / member), billing and plans, usage and limit policies, SSO connections and verified domains, security policy (require-MFA), backups.
Workspace	Where data lives; the tenancy and permission boundary. An organization can own many.	Tables and their schema, records, workspace roles and groups, approval rules, saved queries, charts, dashboards, secrets, API tokens, the audit log.
Table	One kind of thing you track. Entirely user-defined.	Fields, constraints, record-visibility setting, lifecycles (stage fields), derived fields and summaries.
Field	A typed column on a table.	Type and configuration, validation, per-field visibility, stage designation.
Record	A row — the actual data.	Values, an owner, comments, attachments, change history, per-record shares.

Key consequences of the shape:

Workspaces are watertight. Records, references between tables, search, queries — everything operates within one workspace. There are no cross-workspace links, and being an organization owner grants no access to workspace data: administering a workspace and being a member of it are deliberately different things (an org admin can join a workspace, visibly, but never peek into it).
Membership is org-first. People are invited to the organization, and workspace access is a grant on top of that membership. Removing someone from the organization removes them from every workspace it owns.
A fresh signup starts with no organization or workspace. Onboarding asks you to create an organization and then its first workspace; invited users accept their organization invitation instead. Later workspaces are created from Organization Settings → Workspaces.

Deep dives: Organization administration, Workspace administration, Tables and fields, Working with records, and Importing data for getting existing data in.

Roles & permissions

Every capability is a named action (records:read, tables:manage, secrets:manage, …) and every workspace member holds a baseline role — Admin, Member, or Reader — optionally topped up with custom roles. Permissions are additive and default-deny: roles only ever grant, there is no deny list, and what a person can do is the union of everything their roles grant. Separately from actions, record visibility controls which rows and fields a person can see — per-table workspace/private settings, record scopes, sharing, and private fields.

Organization roles (owner / admin / member) are a parallel, management-only axis with their own actions (org:members:manage, org:billing:manage, …) — they never grant workspace data access.

This is the single most important system to understand properly: Authorization & Permissions.

Ways to see data

One table, many surfaces — all reading the same records, all enforcing the same visibility rules:

Views are arrangements of the same data, not copies — a change made in one appears in all, live.

Table view — the record list with filtering and a detail page per record.
Boards — drag-and-drop pipeline lanes over a table with a stage field (see Lifecycles).
Sheets — a full-screen, spreadsheet-style grid with a tab per table, editable in place.
Global search — one box across every table you can read, honouring your row filters and field masking (a record can only be found by fields you’re allowed to see).

Deep dives: Views, Search.

Analytics: queries → charts → dashboards

The analytics pipeline is three layers, each built on the one before:

Queries — ask questions of your data in the query console, save the useful ones, and export results. Running ad-hoc queries is its own permission (query:execute) because a query reads whole tables.
Charts — saved visualisations built on queries and tables.
Dashboards — assemblies of charts and query tables that the whole workspace can view; the AI dashboard assistant can draft one from a description.

Tables can also carry derived data — formula fields, cross-row derived rows, and scheduled summaries — computed by the platform rather than typed by people: see Derived data.

Deep dives: Queries, Dashboards.

Process automation

The systems that govern how work moves, from lightest to strictest:

Lifecycles — designate a picklist field as a stage machine: an ordered pipeline with rules about which stage transitions are allowed. Powers boards and stage history. Lifecycles.
Flows — multi-step automations built under Automations. They can start from record changes, a manual record action, a UTC schedule, or an inbound webhook, then find or write records, send email, call HTTP services, run sandboxed code, branch, loop, wait, or ask for approval. Authors with the relevant Flow permissions edit and test a draft, publish immutable versions, and choose whether record-event runs use the initiating user’s permissions or the flow’s automation identity. Anyone with flows:read can inspect run status, timing, and errors in Automations → Activity; step input and output require flows:update or flows:execute.
Approvals — rules that intercept sensitive changes as pending changes requiring sign-off (approvals:decide) before they apply. Everyone has a My Approvals page for decisions waiting on them. Approvals.

Integrations & secrets

Workspaces connect outward in two directions. Integrations (integrations:manage) are first-class connections to external marketing/email platforms, including audience syncs that keep an external audience matched to your records. Secrets (secrets:manage) are the credential store behind integrations and outbound automation: named, encrypted, write-only values — once saved, a secret can be referenced but never viewed again, only rotated or deleted.

Deep dive: Integrations & secrets.

AI assistants & MCP

Three in-app assistants — schema, query, and dashboard — turn natural-language descriptions into validated proposals that a person with the right permission then applies (e.g. applying a schema plan requires schema:apply); the assistant never gets write access of its own beyond what the applier holds. They are available when AI features are enabled for your organization.

Each workspace also exposes an MCP server (URL in Workspace Settings → AI & MCP), so external AI agents — Claude, IDE agents, and other MCP clients — can describe your schema, query data, and (if the organization has enabled record writes for MCP) create and update records, all through OAuth with scoped permissions.

Deep dive: AI assistants.

API access

Everything the UI does rides on a REST API, and there are two ways in: API tokens (tokens:manage to create) — workspace-bound credentials for scripts and server-to-server integrations — and OAuth, used by MCP clients and third-party apps, with scoped consent. Each workspace publishes its own OpenAPI document (Workspace Settings → API Spec) describing its actual tables and fields, so generated clients match your schema, not a generic one. API callers pass through exactly the same permission and visibility checks as people.

Deep dive: API access.

Notifications & audit

Notifications keep people informed — in-app (the bell), optional browser push, and email — covering things like approval requests and mentions. Audit is the accountability layer: every mutating API call and record change is logged, browsable per workspace (the Audit page, audit:read) with record-level history on each record’s detail page. Organization owners additionally see org-wide usage reporting.

Deep dives: Notifications, Audit.

Plans & limits

Organizations subscribe to a plan, and the plan sets the ceilings: tables and rows per table, stored secrets, storage, and more. Owners and admins manage the subscription, payment details and invoices (org:billing:manage) and can see current usage and effective limits in Organization Settings; workspace admins can see their workspace’s usage against each ceiling — and configure some per-resource quotas within the maxima the organization allows. When a limit is reached the operation is refused with a clear message — nothing is silently dropped.

Deep dives: Billing, Organization administration.

Individual accounts support MFA (authenticator apps, backup codes) and passkeys — see Account security. Organizations can go further: enforce MFA for every member, connect an identity provider, and require SSO for verified email domains — see Enterprise SSO.

FAQ

Is an organization the same as a workspace? No — and the distinction is the heart of the model. The organization is management: who’s in, who pays, security policy, backups. The workspace is data: tables, records, roles, automation. One organization typically owns several workspaces (production CRM, sandbox, a second team’s data), and a person’s role in the organization says nothing about what they can see in any workspace.

Can records reference records in another workspace? No. Reference fields, queries, search and dashboards all operate within one workspace — the workspace is a hard boundary. If two teams need to share data, they share a workspace (with roles and record visibility controlling who sees what).

Do organization owners see everything? They administer everything — workspaces, members, billing — but they do not see workspace data. To read records in a workspace, an org owner/admin must join it as a member, which is visible to everyone in that workspace’s member list. See Authorization & Permissions.

Where do I start? The Quick start walks the whole first-day path: account, first table, records, teammates, and a first dashboard.

Open the app