Quick Start

We will build a small support-ticket application end to end: a datastore, the permissions to reach it, a user who can use it, a dashboard and an API call.

Where to find it

Architect Panel → Data:

• Datastores — steps 1 and 4
• Record Numbering — step 2

Architect Panel → Dashboards:

• Custom Dashboard Blocks — step 7

Architect Panel → Integration & Connections:

• API Clients — step 8

Architect Panel → Automation:

• Tasks — step 9

Steps 3 and 5 are in the Admin Panel sidebar under User Administration, not the Architect Panel — see the note below.

Before you start

• An instance and an administrator account. You reach the admin at /am.admin/ on your domain.
• A current browser. Nothing else — no command line, no local install.

Know which panel you are in

This is the thing that confuses newcomers most, so it is worth thirty seconds now.

• The Architect Panel is where you build — datastores, pages, permissions, automation, integrations.
• The Admin Panel sidebar is where you administer day to day — under User Administration you will find All Users and User Groups.

Both are reached from the same admin home. If a screen in this guide is not where you expect, check which of the two you are in.

Step 1 — Create the datastore

Architect Panel → Data → Datastores → new record.

Name it Ticket and add fields: a reference, a subject (required), a status dropdown (open / pending / resolved), a severity dropdown, an owner and a created date defaulting to now.

On saving, the platform creates the table, the create, edit and view forms, a browse view, search index entries, API endpoints and audit logging. There is nothing further to generate.

Step 2 — Give it a reference format

Architect Panel → Data → Record Numbering.

Create a scheme against the Ticket datastore's reference field with prefix TKT and padding of five, so tickets read TKT-00001 rather than quoting a database ID.

Step 3 — Create a security group

Admin Panel sidebar → User Administration → User Groups → new record. Name it Agent.

Groups are created here, not in the Architect Panel — the Architect Panel is where you grant a group access to things, which is the next step.

Step 4 — Grant the group access to the datastore

Architect Panel → Data → Datastores, find your Ticket row, and use its Permissions row action.

Grant the Agent group what it needs. Access is grant-only: anything you do not grant is not permitted, so there is no deny list to reason about.

Row actions are worth noticing generally — the Datastores list also carries Table Designer, View Data and Duplicate Rules. A good deal of the platform is reached this way rather than from a menu.

Step 5 — Put a user in the group

Admin Panel sidebar → User Administration → All Users, find the user, and use the Manage Security Groups row action.

Add them to Agent. They can now reach tickets, and only tickets.

Step 6 — Check it as they will see it

Before going further, confirm the access is what you intended by looking at the application as that user rather than as an administrator. Administrators see everything, which makes an administrator's view useless for verifying permissions.

Step 7 — Add a dashboard block

Architect Panel → Dashboards → Custom Dashboard Blocks.

Add a counter bound to Ticket filtered to status = open. It appears for anybody whose permissions let them see tickets, and nobody else.

Step 8 — Call the API

Architect Panel → Integration & Connections → API Clients.

Create a client, take its credentials, and call the Ticket endpoint. The API was generated with the datastore in step 1 — the client is the only new thing here. The OpenAPI Specification item in the same section describes what is available.

Step 9 — Turn on the audit chain

Architect Panel → Automation → Tasks, and enable Audit Chain Sealing.

Do this now rather than later. It seals audit history so that alteration is detectable, and it can only evidence the period since you enabled it.

What you have

A working multi-user application with its own reference numbers, permissions, a dashboard, an API and a tamper-evident audit trail — none of which required code.

Worked example

A team following this guide had a usable internal ticket log the same morning. The parts that took longest were deciding the status list and realising that groups are created in the Admin Panel while permissions are granted in the Architect Panel — which is the one thing worth reading twice.

Recommendations

• Get the fields right before building anything on them.
• Always verify permissions as a real user, never as an administrator.
• Set up numbering at the start — retrofitting references is awkward.
• Enable audit chain sealing on day one.