docs.index.title

docs.index.lede

Getting StartedWelcome! This page walks you through your first sign-in: logging in, choosing a work space, and finding your way around the main screen. It takes about five minutes.
Your DashboardYour dashboard is the home screen you land on after signing in (the **Dashboard** row at the top of the menu). It is built from *widgets* — small self-contained tiles that each show one thing: a number, a list, a chart, or a table.
Widgets: the full guideA *widget* is one card on a page: a number, a chart, a list, a table, a block of text, a goal, a record's fields. Dashboards, record pages and the other widget pages are all made of widgets. This page explains how a widget is built and who can see it. Each kind has its own section on its kind's page:
Menus & NavigationThe sidebar you see is not fixed. Every option on it is a row an administrator can rename, re-order, hide, point somewhere else, or show only to certain groups of people. This page explains that screen and the one idea behind it.
Dashboard widgets: numbers, charts, lists and tablesThese six widgets are what dashboards are made of. Each one is built in the widget builder: you pick the kind under **How should this data look?**, a source under **Where does the data come from?**, then its **Display options** and an optional **Filter**. How the builder works as a whole, and the **Custom widget** that stacks several of them in one card, is on [Widgets: the full guide](/docs/widgets).
The Page Designer & Widget LibraryDashboards and other widget pages are assembled, not programmed. Two screens do it: a **library** of reusable widgets, and a **designer** that places them on a page. Nothing here needs a deployment — a page shows your change the next time it loads.
TranslationsEvery word the interface shows comes from a string with a key. The Translations page lets you read that catalogue and rewrite any value in it — so "Contacts" can become "Clients", "Spaces" can become "Branches", and a confusing message can be reworded for your own people.
Record-page widgetsA record page, such as a contact's page (`/contacts/<id>`), is a widget page that shows one record. Its cards are widgets that read that record: its own fields, the rows of its extension tables, its links, its files and its messages. They are built in the widget builder like any other widget, and placed on the page in the Page Designer. How the builder works as a whole is on [Widgets: the full guide](/docs/widgets).
Work widgetsSix widgets show [work items](/docs/work-items). Three are about the person looking or a whole pipeline, and they suit a dashboard: **My work**, the **Pipeline funnel** and the **Timeline**. The other three show one work item, and they belong on a work item's page: the **Work item header**, the **Checklist** and **Work-item comments**. The *My work* page and a work item's page are built from these widgets. Like every widget, they are built in the widget builder and placed in the Page Designer; how the builder works as a whole is on [Widgets: the full guide](/docs/widgets).
Scheduling widgetsNine widgets show the [schedule](/docs/scheduling). Four of them draw the events of a **view** of events you choose: the **Calendar**, **Schedule lanes**, the **Agenda** and the **Dispatch tray**. The other five read their own data: the **Budget strip**, the **Roster**, **Needs attention**, **Open shifts** and **Schedule requests**. The *Schedule* page is built from the last three. Like every widget, they are built in the widget builder and placed in the Page Designer; how the builder works as a whole is on [Widgets: the full guide](/docs/widgets).
Working with ListsEvery list of records in the app works the same way: **Contacts**, every list you open from the sidebar, and every list a designer has built as a view. They share one table with one set of tools, so once you know one list you know them all.
Designing Table ViewsA **view** is a designed table: a chosen set of columns over a chosen source, with a filter and a sort order saved alongside it. Everybody who opens the view sees the same design. This is different from a *saved view* on an ordinary list, which is your own arrangement of an existing table — see [Working with Lists](/docs/lists) for those.
Filtering & SearchingThere are two ways to find records in a list: type into **quick search**, or build exact conditions in the **filter builder**. This page explains both, every operator the builder offers, and seven worked examples you can copy. The pictures were taken on the Globex sample space, over a sample view of its contacts.
Adding & Editing RecordsNothing in this app saves behind your back. On a record's page you switch to edit mode, change what you need and press **Save**. In a list, your changes wait in an edit cart until you save them. If someone else changed the same record first, the app stops and tells you, and in the edit cart it shows you both versions. This page walks through each of these.
ContactsA contact is the record for one person or organization, and the hub for everything you know about them. This page tours a contact from top to bottom, then covers sharing contacts with other spaces.
Roles & Extension FieldsRoles are the reason record pages configure themselves. A role tags what a contact *is* — a client, a member, a parent — and each role brings its own panels of extra fields along. Add the role, and the panels appear; no page setup, no waiting for a developer.
Form LayoutsEvery form in the application renders from a **layout definition**. If no one has written one, it renders its built-in default. This page is where a layout is written, and — just as importantly — where it is taken away again.
Value ListsA **value list** is a named, ordered set of choices: statuses, priorities, categories, referral sources. Any extension field of type **List** picks one by name, and every field that uses it offers exactly the options you define here.
Required DataMaking a field required is easy. Making it *true* is the hard part: the moment you declare it, the records that already exist are still missing it. This page is about that gap — what is missing, how much of it, where the values are coming from, and the two buttons that move a field from "the application refuses it" to "the database refuses it".
Custom & Computed FieldsCustom fields add data to a record without changing the application. Three kinds exist, and the difference between them is **who fills them in**:
Data GroupsA **data group** is a named bucket contacts are assigned to: a branch, a caseload, a cohort, a mailing audience. Groups can be nested, so a group can live inside another one, and one group per space is the **default** that receives every new contact.
Linking RecordsRecords rarely live alone: a child has parents, a client was referred by someone, a file belongs to a case. Links connect records to each other, with readable wording in both directions and rules that keep the connections sensible.
Shared Records & Sync ProposalsA contact can be shared from one space into another. When it is shared as a **linked copy**, the original space keeps the master, and your space holds a copy that stays in step with it — but never behind your back. Every change the owner makes arrives in your space as a **proposal** that somebody has to accept.
TemplatesSet up one space well, and you should never have to rebuild that setup by hand. A template packages a space's configuration so it can be applied to another space in one step — and later compared, updated, and re-extracted.
Importing & ExportingBring data in from spreadsheets, other systems, or contact files — and get it back out as CSV or JSON. Imports are guided, resumable jobs: you can load a file today, finish the column mapping tomorrow, and nothing is written to your real data until you press **Start import**.
AutomationsWorkflows automate the repetitive work: update records when something changes, send notifications, call other systems, or run whole processes like an import. You build them visually as a flowchart of steps, preview them safely, and watch every run in a searchable history.
Work ItemsA **work item** is a piece of work: a task, a job, a case, a request. Items nest, so a job can hold sub-jobs and those can hold tasks. They move through stages (see [Pipelines](/docs/pipelines)), can be assigned to a person or a group, and can be created from a form somebody outside your organisation filled in.
PipelinesA **pipeline** is the set of stages a work item moves through, plus the rules about moving between them. It is what the columns on the work board are, and what a refused move is refused by.
GoalsA **goal** is a target with a period, measured by something the system already knows how to count. It does not introduce a new way of recording numbers — it points at an existing measurement and says *this is the number we are aiming at, between these dates*.
SchedulingScheduling has two halves. The calendar is where events are seen and arranged; the setup pages decide what a valid schedule *is* — which events exist, what rules they must satisfy, who those rules apply to, and when people are available at all.
Billing & PlansYour space runs on a plan that defines what is included — users, storage, workflow runs, and other metered resources — and what happens when you reach a limit. This page explains how to read your usage, what the plan types mean, and where invoices live.
IntegrationsConnect the CRM to the other software you use — accounting, payments, help desk, email, SMS, and phone systems — so records flow both ways without copy-paste. Each connection is set up once, monitored continuously, and can be paused or removed at any time.
The Phone SystemThe application runs a real phone system: extensions people dial, teams that ring together, keypad menus, hold music, recorded call history. This page covers both ends of it — the administrator's screens, and the two pages that belong to you.
Conversations & Mailbox AccessEmail, SMS and calls are attached to the contacts they concern, so a contact's record carries the conversation as well as the data. Three screens manage that: the threads themselves, a queue for inbound messages that could not be matched to anybody, and the grants that decide who may read a mailbox.
NotificationsThe bell in the header keeps you informed: records shared with you or assigned to you, imports finishing, approvals waiting on you, workflow failures, integration problems, alerts and more. Everything arrives in one inbox, updates live, and is tunable per notification type.
AlertsAn **alert rule** watches a table for a condition, badges the records that match, and sends the alert. It is for the things nobody will notice by looking: a date coming due, a required value still missing, a record with no active link.
Who Can See WhatEvery button you see, every list you can open, and every action you can take is controlled by permissions. This page explains the model in plain language — what a permission is, how permission groups work, why a space can cap what anyone can do inside it, and how to find out exactly *why* someone can or cannot do something.
Users & SpacesA **space** is a separate work area with its own data and settings; a **user** is a login inside one. These two screens are how people get in and how a space is bounded.
Guest AccessWork can be shared with somebody outside your organisation — a client, a referrer, a contractor. **Guest access** is the policy that decides what they may see and do. This page sets the space-wide boundary and the defaults, lists every share that exists, and individual shares then work inside it.
SettingsAlmost every tunable in the system — page sizes, export caps, import behavior, notification recipients, feature toggles — lives in one consistent **settings cascade**. Understanding the cascade once means every settings screen works the same way.
Maintenance & ConformanceTwo kinds of thing run in the background on a schedule. **Sweeps** keep the system tidy — clearing out what has expired, finishing what was left half-done. **Conformance runners** prove a subsystem still works and raise the alarm when it does not. Each has its own page, and each gives you the same two facts: when it last ran, and what happened.
Inter-app Data GrantsThe system is not one program. The CRM, the phone system, the workflows engine and the portal each run on their own, with their own data. Sometimes one of them needs to read something that belongs to another — the workflows engine wants the list of doctors the CRM keeps, so a workflow can be built around it.
FilesFiles live in the space, in folders, with versions — and they can be attached to contacts, shared by link, requested from somebody, and sent for signature. A contact's own files also show on the contact's page (see *Files on a record* below).
Your AccountYour sign-in details, your language, your password, your rights, your default space and signing out all start from the user menu — the button with your initial and your username at the bottom of the navigation column on the left.
Tips & ShortcutsA collection of small habits that make daily work noticeably faster.
What's NewRelease notes, newest first. The **version badge in the header** always names the release you are running right now; match it against the sections below to see what is included.