> For the complete documentation index, see [llms.txt](https://docs.cw.crisisworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.cw.crisisworks.com/concepts-and-fundamentals/concepts-and-fundamentals.md).

# Terminology

This page describes some of the key terms and concepts you may come across.

The system supports a highly flexible and modular configuration while maintaining a consistent and user-friendly approach to data management.

It features a unified, end-to-end workflow that provides effective management of data throughout its entire lifecycle.

By learning some system basics, you will quickly gain the confidence to navigate and perform tasks in any module.

If you're familiar with some of these terms you can skip straight to a guide on using it on your preferred device.

## Events, Users, Positions and Duty <a href="#events-users-positions-duty" id="events-users-positions-duty"></a>

At the core of the system are **Events**. They provide a secure way to organise work around themes, topics and incidents. Create an event whenever a planned or unplanned activity needs the system. Events define required functions. They determine which positions and resources you use. They also control which **Users** can access the event through the user competency system.

**Users** are individuals who can log in to the system.

**Positions** define a user's permissions and determine what they can access.

To participate in an Event, a user must:

* Be assigned a **Position** within that event
* Go **On Duty** with that Position

The system allows users to be on or off-duty for multiple positions across multiple events simultaneously.

Being **On Duty** makes the user available to accept task assignments and receive notifications.

### Registers <a href="#register-assets-and-resources" id="register-assets-and-resources"></a>

Each event includes a set of **Registers**. Registers are structured databases that store specific information types. The system calls each record an **Item** and lists these on a **Datagrid**. Registers have defined structure and workflow rules and available **Positions**, **Assets** and **Resources**.

To manage register items, users must **go on duty** with a **Position** that has access to that register.

### Assets and Resources <a href="#register-assets-and-resources" id="register-assets-and-resources"></a>

**Assets** are typically locations or properties related to the Event. These can be homes, businesses,  community facilities or even transport stops and services.

Assets refers to the built-in geospatial database (also known as cadastral data) used to search for things by name and location. The Assets system can even include things that are non in fixed positions and allows additional information to be added (such as owner information). This supports a diverse range of items from roads to private land parcels, bridges, parks, civic buildings to public transit stations and even individual vehicles.

As some Asset data is sensitive, management of it by users is limited and secured.

The Assets system is typically set up when your system is configured [along with mapping](/concepts-and-fundamentals/on-a-computer/mapping-and-assets.md) using available data for your local area. It may even be synchronised to your device for [access offline](/concepts-and-fundamentals/mobile-app/working-offline.md).

## Modules <a href="#modules" id="modules"></a>

**Modules** group registers, positions and resources. They appear in the main navigation menus.

Core modules include:

* **Dashboard**
* **Reports**
* **System Administration**

Other modules are configured for specific tasks.

The modules users have access to depends on the events they join, their positions and duties they sign in with.

While modules are typically configured when your system is set up, access to registers and functions within events is configured by your system administrator.

### Workflow and Communications <a href="#workflow-and-communications" id="workflow-and-communications"></a>

Depending on the configuration of each module, registers are used in combination to perform various actions. Items may be **assigned** to users and positions, and can utilise resources and relate to assets.

Additionally, registers implement **workflows** using combinations of **status**, **priority**, **assignment**, **counters**, **escalations**, **notifications** and **communications**, which help users and teams to effectively manage an event.

At every step of the way each change is audited, and data within each register item must conform to its workflow rules and schema constraints, meaning nothing is lost or forgotten.

Administrators can import data, including data from other systems for management in bulk. Data sharing is automated via the Application Programming Interface (API).

Built-in reports provide analysis, summarisation and data sharing with others.

### Sites and Regions <a href="#sites-and-regions" id="sites-and-regions"></a>

Your organisation may have multiple instances of the system called **Sites**. These Sites usually share the same modules, registers and functionality but with a separate sets of events.

{% hint style="info" %}
Sites are created set by Datalink, not your administrator. To add sites to your system, contact the [Service Desk](/security-and-support/maintenance-and-support/accessing-support.md).
{% endhint %}

There are a couple of advanced configurations where information is shared across a single Site or multiple sites:

* **Multi-Site** - a deployment which features multiple Sites used simultaneously that users with sufficient privileges can navigate between. This is sometimes set up before the launch of the main Site during testing and training. Rarely it is used in enterprise deployments where there are multiple separate departments or organisations using the same configuration but independently of each other.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.cw.crisisworks.com/concepts-and-fundamentals/concepts-and-fundamentals.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.