Start here

Audience: the consultant delivering an engagement on TTP Enterprise. Read this first. It gives you the mental model and the reading order. Nothing else in the guide assumes you have read anything but this page.

What this platform is

TTP Enterprise is a metadata-driven application platform. You do not write code to deliver a client application — you configure one, and the platform deploys and runs it. Everything a delivered app is (its data shape, its screens, its rules, its permissions, its look) is stored as configuration, versioned, and shipped as a unit.

Think of it as four layers:

The single most important consequence: a delivered app is configuration, so changing it is a config change, not a code deploy. That is why the whole product is organised around authoring, publishing, and deploying configuration safely.

The three scopes, and the three modes

The left sidebar shows exactly one scope at a time. This is the map of the product:

FIRM ─────────────► your consultancy: clients, rates, billing, branding,
                    operators & roles, security, compliance, platform health
  │
  └── CUSTOMER ───► one client company: their profile, engagements, portal
                    users, billing
        │
        └── ENGAGEMENT ──► one piece of work for that client. Has THREE MODES:
              │
              ├── OPERATE ─► the commercial relationship: scope, delivery,
              │              change orders, contracts, invoices & time,
              │              progress reports, disputes, team, portal users
              │
              ├── BUILD ───► authoring the app: schema, pages, behavior,
              │              permissions, appearance, connections, data import,
              │              watchers, surfacing, escalations, roles, deploy config
              │
              └── RUN ─────► the app in production: app data, attention,
                             deployments, health, incidents, logs, support,
                             releases, topology, workflow runs, anomaly events,
                             lineage, audit

If you are ever lost, ask: which scope am I in, and if it’s an engagement, which mode? Almost every “I can’t find X” is a scope/mode question.

Who the people are — the four seats

The scopes above say where things live. This says who the people are. They are four different kinds of account, stored in four different places, and they never overlap.

flowchart TD
  PO["<b>PLATFORM OPERATOR</b><br/>TTP itself — one workspace<br/>creates firms · plans · suspends<br/><i>sees every firm</i>"]

  subgraph FIRM["YOUR FIRM — one Workspace"]
    OADM["<b>OPERATOR</b> · role <code>admin</code><br/>runs the consultancy"]
    OBIL["<b>OPERATOR</b> · role <code>billing</code>"]
    OBLD["<b>OPERATOR</b> · role <code>build</code><br/>builds the app"]
  end

  subgraph ENG["ONE ENGAGEMENT"]
    CU["<b>PORTAL USER</b><br/>your client's sponsor<br/>magic link — no password<br/><i>sees one engagement</i>"]
  end

  subgraph APP["ONE DEPLOYED APP — its own database"]
    AADM["<b>APP USER</b> · role <code>admin</code><br/>permissions <code>['*']</code>"]
    AMEM["<b>APP USER</b> · role <code>member</code><br/>permissions <code>[]</code> until granted"]
  end

  PO -->|provisions the firm,<br/>invites its first admin| OADM
  OADM -->|invites| OBIL
  OADM -->|invites| OBLD
  OBLD -->|builds and deploys| APP
  OADM -->|invites to the portal| CU

⚠️ Three traps in the vocabulary

1. “admin” means three unrelated things. Which one is meant is never obvious from the word alone:

A client’s app admin has ['*'] inside their app and no standing at all in your firm. The other direction is a capability, not a wall: reading or changing a client app’s schema, pages or records from the studio needs build_apps, which your admin and build seats hold and a billing seat does not.

2. operatorId is a FIRM, not a person. The column name reads like it points at an Operator — a human being. It does not: it holds a workspace id, and the code keeps operatorId === workspaceId deliberately. So ClientUser.operatorId means “the firm that owns this portal user”, and an app limit counted “per operator” is counted per firm. An Operator row, confusingly, is a person.

3. A portal user is scoped to one engagement, not to the client. The same human at the same client, sponsoring two engagements, is two ClientUser rows with two links. There is no single account that spans their engagements.

4. Some decisions are the client’s, and live only in their portal. The clearest one is Approve for production on a change request: the operator screens have no such button by design, because it is not the firm’s call to make. If you are looking for a control and cannot find it, check whether it belongs to the other side — see Client collaboration.

⚠️ And a control can be absent because the engagement is set up differently, not because it is missing: an engagement with no preview site has no client-approval step at all, and both screens say so rather than showing a step that never arrives.

The engagement spine

An engagement moves through the same arc every time. The guide is organised along it:

  discover ─► scope & contract ─► BUILD the app ─► deploy ─► RUN it ─► invoice ─► hand off

Reading order

Read in this order the first time. Each page assumes the ones before it.

⚠️ Before any of those: When something is wrong — the diagnostic order and the symptom → cause → action index. It is the page to reach for when you are stuck now.

Two more, for other audiences, that you should skim so you know what your client sees:

• End-user app guide — what your client’s staff see in the delivered app.
• Portal client guide — what your client’s stakeholders see in the portal.

How to trust this guide

Every page in this guide is in the maintained set and is checked by CI: every route, file and command it names must actually exist, and every page is anchored to the source it describes so that changing that source turns the page red until someone re-reads it. Those checks are mechanical — they prove the things this guide points at are real. They cannot prove the prose is wise.

Where a capability is partial or known-broken, this guide says so in place rather than quietly omitting it. If you find a step you cannot perform, that is a bug in the docs and should be fixed the same way a bug in the product would be.