How Qik Is Organised
Everything in Qik fits into a small number of building blocks: your organisation, the scopes that divide it up, the content types that describe what kind of information you keep, and the individual records you create. Once you understand how these fit together, the rest of the dashboard (permissions, forms, workflows, smart lists, apps) makes a lot more sense.
The big picture
Think of Qik as layers, from the outside in:
- Organisation — your account. Everything you create belongs to exactly one organisation and is never visible to other organisations.
- Scopes — a tree of areas inside your organisation (for example Acme → Sydney Office → Sales Team). Every record lives in one or more scopes, and permissions are granted per scope.
- Content types — the kinds of record you keep: people, events, articles, files, form submissions and any custom types you design yourself.
- Records — the individual items: a person called Jane Smith, a training session next Tuesday, a policy document.
Organisation
Your organisation is the container for all of your data, your users, your apps and your settings. A single person can belong to more than one organisation with the same email address and switch between them from the account menu (Switch Organisation), but data never crosses between organisations.
Scopes: where records live
A scope is an area of your organisation. Scopes are arranged in a tree: each scope can have a parent, so you can model regions, departments, campuses, teams or anything else that suits the way you work. For example, Riverbank College might use:
- Riverbank College
- North Campus
- Science Department
- Sports Department
- South Campus
- North Campus
Every record is stored in at least one scope, and it can be in several at once. Scopes matter for two reasons:
- Permissions cascade down the tree. When someone is given a role in a scope, that role also applies to every scope underneath it. A manager given access to North Campus can work with records in the Science and Sports departments too, but not with records that only live in South Campus.
- Organising and filtering. Lists, smart lists and exports can be narrowed to particular scopes.
Some scopes can also be set to act as a group — a smaller unit such as a team or class that people can belong to, with positions like leader or member. See Scopes and Groups for the details, and User Access Control for how roles and scopes combine.
Content types
A content type describes one kind of record: what it is called, which fields it has and how it behaves. There are three ideas to keep apart.
1. Built-in (base) types
Qik comes with a set of built-in types that have their own special behaviour. Some of the most common are:
| Type | What it is for |
|---|---|
| Person (profile) | A record about a human being: names, contact details, date of birth, relationships, group memberships. |
| Event | Something that happens at a time: a workshop, a match, a conference session. Supports check-ins, rosters and tickets. |
| Article | Text content with a title and rich-text body, such as news posts or knowledge-base pages. |
| Custom Object | A clean slate with only the basic fields, for anything that doesn't fit another type. |
| Image, Video, Audio, File | Uploaded media and documents. |
| Form Submission | The answers someone gave on one of your forms. |
| Workflow Card | An item moving through one of your workflows. |
Which built-in types you see depends on the features enabled for your organisation and on your own permissions.
2. Custom content types (definitions)
A custom content type — called a definition in some parts of the dashboard — is a new, separate type that you design. It extends one of the built-in types, inherits that type's behaviour, and adds your own fields. For example:
- A Workshop type that extends Event, adding fields for Skill level and Equipment needed.
- A Policy Document type that extends Article, adding Review date and Owner department.
- A Site Inspection type that extends Custom Object, for a construction firm's inspection records.
Records of a custom type have their own list, their own permissions and their own place in the glossary. Workshops and ordinary events are both events (they appear together when you look at all events), but you can list, filter and grant access to Workshops on their own. Forms and workflows are also content types under the hood: every form defines a submission type and every workflow defines a card type.
See Creating Definitions (Content Types) for how to build one.
3. Custom fieldsets (custom fields)
A custom fieldset does not create a new type. Instead, it adds extra fields to every record of a built-in type. The most common use is people: if you want every person in your database to have an Emergency contact or a Staff ID, you add a custom fieldset to Person. Those fields then appear on every profile, everywhere.
Which one should I use?
| You want to… | Use |
|---|---|
| Track extra information about all people (or all events, all images…) | A custom fieldset |
| Keep a distinct kind of thing with its own list and its own permissions | A custom content type |
| Store information about people | Always the built-in Person type plus custom fieldsets. Qik aims for one profile per real person, so people aren't modelled as a custom type. |
Custom fieldsets are managed from System → Custom Fields (New Custom Fieldset), and people-specific fields are also reachable from People → Custom Profile Fields. See Custom Fields.
Records and their common details
Every record, whatever its type, carries the same set of common details (often called its meta data) alongside its own fields:
| Detail | What it means |
|---|---|
| Title | The record's name. For some types (such as people) it is built automatically from other fields. |
| Status | active (the default) or inactive. Inactive records are kept but left out of lists unless you filter by status. Some types can also be given an activate and deactivate date so the status changes automatically. |
| Security | Secure (the default) means only signed-in users and apps with the right permissions can see the record. Public means it can be read over the internet without signing in — useful for content shown on a public website. |
| Scopes | Where the record lives (at least one). This decides who can see and edit it. |
| Tags | Labels for grouping and searching. See Tags and Tagging. |
| Slug | A human-readable, unique identifier (for example annual-report-2026), generated from the title if you leave it blank. Used in website addresses. |
| Description | An optional one-line summary. |
| Created / Updated | When the record was created and last changed. |
| Author and owners | Who (or which app or automation) created the record, and any users marked as its owners. Roles can include "own" permissions that only apply to records a user created or owns. |
Your own fields — the ones defined by a custom content type or a custom fieldset — sit alongside these details.
The glossary
The Glossary is the complete list of every content type in your organisation that you have access to: built-in types and all of your custom types. To open it, go to System in the sidebar and click Show me everything.
The glossary is split into tabs:
- Content — built-in and custom types, grouped by category.
- Forms — every form, with a View Form shortcut.
- Workflows — every workflow's card type.
- Templates — email templates.
- System — system-level types such as users, roles and logs.
Click any type to open its list. The ⋯ button next to a custom type opens its options (for example editing its fields), and if you are allowed to create content types, the New button at the top starts a new one.
The glossary is permission-aware: people only see types they have some access to, so two users may see different glossaries.
Putting it together: an example
Northside Football Club sets up Qik like this:
- Scopes: Northside FC → Seniors, Juniors → Under 12s, Under 14s.
- A custom fieldset on Person adds Membership number and Medical notes to every profile.
- A custom content type Match extends Event, adding Opponent and Final score.
- The Juniors coordinator is given an editing role in the Juniors scope, so they can manage Under 12s and Under 14s records but not Seniors.
Tips
- Sketch your scope tree before importing lots of data. Because permissions follow the tree, its shape decides who can see what.
- Prefer a custom fieldset when the information belongs to every record of a type; reach for a custom content type only when you need a genuinely different kind of record.
- Leave records Secure unless they really need to be visible to the public.