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. It is built from *widgets* — small self-contained tiles that each show one thing: a number, a list, a chart, or a table.
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.
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.
Working with ListsEvery list of records in the app — All Contacts, People, and any saved view — is the same table with the same tools. Learn it once and you know every list.
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: type into **quick search**, or build precise conditions in the **filter builder**. This page explains both, with worked examples you can copy.
Adding & Editing RecordsNothing in this app saves behind your back. Edits collect where you can see them, you save when you are ready, and if someone else changed the same record first, you decide what happens. This page shows the whole editing flow.
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 field mapping tomorrow, and nothing is written to your real data until you confirm.
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, test 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, and system alerts. 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.
Your AccountYour profile, language, password, and default workspace all live under the user menu — the avatar button at the far right of the header.
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.