Audience: consultant. Prerequisite: the rest of the guide.
What the platform genuinely cannot do yet — the things worth saying out loud to a client before they are discovered mid-engagement.
Diagnosing a specific symptom? That moved to When something is wrong, which is now the first page of the guide. It holds the diagnostic order and the symptom → cause → action index. Everything below is about limits, not faults.
Known gaps — say these out loud to clients
Being straight about these is cheaper than discovering them mid-engagement.
| Gap | Reality |
|---|---|
| Document generation | the Request document workflow node records an auditable request. No PDF is rendered — there is no render service. Do not promise a generated document. |
| Approval instances | an approval instance is minted only by a workflow’s human-approval node; there is no standalone “create an approval” API, so approvals are exercised through a workflow. |
| Pre-auth portal branding | the portal’s sign-in page is TTP-branded, not operator-branded. Post-auth carries your logo. |
| Some connector types | REST and GraphQL are proven end to end. SQL and SFTP are scaffolded; verify against the client’s actual source before committing to a date. |
| Client sign-off needs a preview site | the client approves a change for production only once it is live on a preview target — a separate deployment with its own database, so it is real recurring infrastructure rather than a setting. Without one a change goes In progress → Live and the client is not asked. ⚙️ Both the change-order screen and the client’s portal now say which shape the engagement is on. Add a preview from Build ▸ Deploy (Staging) when a client should sign off first. |
| Client sign-off is reported, not enforced | the ladder records the client’s approval; it does not gate the deploy. A production deploy marks the change Live whether or not the client pressed the button. Treat the label as reporting, not as a lock on the release. |
| Seed data only ships on the FIRST deploy | seed/demo records are bootstrapped when an app is created and are never re-applied on a redeploy — deliberately, so a redeploy can never overwrite the client’s live data. ⚙️ The Deploy screen now says so per row (“first install only”), with the reason in full underneath. To change data in a running app, change it IN the app or import it; editing the seed and redeploying will not move it. |
| An approved change order does not bill | approving a quote seeds the scope item so the work can start — and raises no invoice, deliberately: an invoice appearing without anyone deciding to send it is the same class as a stage advancing on someone else’s deploy. ⚙️ You are reminded: Engagement ▸ Invoices carries an approved and unbilled worklist covering both kinds of change order, and raising the invoice from that list is what records the link. ⚠️ A row with no link that predates the field reads as unknown, not as unbilled — it may well have been billed by hand. |
Silent failure is treated as a bug
The platform’s standing position: a write that fails must say so. A rejected save that closes the dialog as if it worked is a defect, not a quirk. There is a CI guard that fails the build when a builder mutation reports success to the user but says nothing on failure.
Similarly, the platform prefers loud misconfiguration over silent substitution: a missing theme reference, a dead nav entry, or a watcher that can never notify raise a configuration issue rather than quietly falling back to a default.
⇒ The consequence for you as a user — if nothing happens at all, report it — is in When something is wrong, along with how to report it.