# Terminology

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.

{% if  %}

### 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).

{% if visitor.claims.platforms.cw === true %}
Administrators can also import data into the system using the [Imports](/system-administration/configuring-the-system/imports.md) module, including: [Roads](/system-administration/configuring-the-system/imports/assets/asset-road-general-import.md), [Infrastructure](/system-administration/configuring-the-system/imports/assets/assets.md), [Private Assets](/system-administration/configuring-the-system/imports/register-items/private-assets-import.md), [Asset Contacts](/system-administration/configuring-the-system/imports/assets/asset-contacts.md) or [Points of Interest](/system-administration/configuring-the-system/imports/assets/asset-point-of-interest-general-import.md). Note that your system may be preconfigured with mapping data for your local region, so it is best to contact the [Service Desk](/security-and-support/maintenance-and-support/accessing-support.md) for advice prior to importing assets.

For assistance with supplying your own asset data for asset lookups please also contact the [Service Desk](/security-and-support/maintenance-and-support/accessing-support.md).

**Resources** include people, equipment, services or organisations that support an Event. They are assigned to items and tracked across the event.

<figure><img src="/files/wrQkD2z7kw3EE26EbUnk" alt=""><figcaption><p>Structure of Events, Registers, Positions, Resources and Assets</p></figcaption></figure>
{% endif %}
{% endif %}

## 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.

{% if visitor.claims.platforms.cw === true %}
Examples of such tasks include [Operations](broken://pages/rGTm9vyCA4TordShc02E), [Recovery](broken://pages/iX5K34MTmeOQC8xMW0Kw), Assessments and [Inspections](broken://pages/LWZIZDhZ8JtpWRjyzxDN).
{% endif %}

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

{% if visitor.claims.platforms.feims === true %}

### FCMS Modules

FCMS consists of the following main modules:

1. [Mobile](/concepts-and-fundamentals/mobile-app.md) - the main interface used by officers of different levels. The mobile app contains its own workflows for setting up deployments, journal activities and interactions.
2.

### Deployments

A Deployment represents a given sub-team for a given shift. Senior Transport Officers create these by [managing Events](/system-administration/managing-events.md).

You join a deployment at the beginning of each shift. Joining a deployment is known as going on duty to that event. You may occasionally switch deployments during your shift if your team structure changes. You must also leave a deployment by going off duty.

### Journal Activities

Activities are what officers do during a deployment.

* Record both “Patrol” and “Non-Patrol” activities in the journal
* “Group” activities involve your whole deployment, while “Individual” activities apply only to you

Each new activity automatically closes the previous one.

**Group Activities**

Group activities involve all (or most) of your sub-team.

Only one person in your sub-team needs to enter the group activity. The system shares it with all officers in that sub-team.

<figure><img src="/files/iC9nOBCPwbySzH7cv5nv" alt=""><figcaption><p>The system copies group activities to individual journals</p></figcaption></figure>

**Individual Activities**

Individual activities are used if you are doing something different than the rest of your sub-team.

When you have an individual activity, you won’t receive group activities to your journal.

Individual activities apply just to you, and they override all group activity.

When you have an individual activity, your journal will not include any updates to group activities.

This is used for scenarios such as:

* Admin duties
* Breaks
* Split patrols\*

<figure><img src="/files/9fZiCB4Gtumhu4zlgyHx" alt=""><figcaption><p>Individual activities vs Group activities</p></figcaption></figure>

**Static Patrols**

A static patrol happens at stops, stations and wharfs.

A static bus patrol keeps the bus stop activity open while you patrol.

<figure><img src="/files/K8Cdm0YgiQfs7PGpsnYX" alt=""><figcaption><p>Overview of a Static Patrol Activity</p></figcaption></figure>

**Mobile Patrols**

Mobile patrols occur on train, light rail and ferry services.

### Interactions

Interactions record any interaction with customers and is the way to issue fines and cautions.

It includes:

* A guided smart form
* Evidence collection (ORPA, Camera, GPS)
* Customer details
* Infringement details
* Fines and Cautions

### Notices

Someone must review and approve interactions before the system issues **notices**.

1. You complete the interaction in the presence of the customer
2. Later, you or a partner can review and edit your interactions
3. After you approve the interaction, the system generates the notice

This workflow helps find and minimise errors and helps improve your recordkeeping in case the interaction goes to court.
{% endif %}

{% if visitor.claims.platforms.feims === true %}

### FEIMS Modules

FEIMS consists of the following main modules:

1. [Mobile](/concepts-and-fundamentals/mobile-app.md) - the main interface used by officers of different levels. The mobile app contains its own workflows for setting up patrols and guiding interactions.
2. Revenue Protection - used to manage interactions and incidents
3. Fines & Investigations - used to manage offenders, penalties and warnings
4. Officers - used to manage officers and system users
5. Reports - used to extract key information and statistics

### FEIMS Users and Officers

There are different levels of users:

1. Senior Network Officers with a mobile tool to issue infringements, match offender details, track their activities and record and respond to incidents;
2. Fines and Investigations Unit Officers with a database management platform to manage the lifecycle of penalty and warning notices issued by authorised officers including entering paper notices, managing adjudications, creating correspondence and working with TRAILS, SPER and other systems;
3. Revenue Protection Unit Officers with the ability to generate detailed reports on their activities from the perspective of officer performance, service provision to operators and joint police operations to name a few; and
4. External parties such as Queensland Rail Officers with limited access to search offenders;
5. The general public with a way to access electronic authority to travel flash cards, and access to download electronic notices;
6. Administrators with aids such as resource tracking, reference materials, user management, security and audit.

### Shifts and Patrols

A shift or patrol is an Senior Network Officers create these by [managing Events](/system-administration/managing-events.md).

You join a patrol at the beginning of each shift. Joining a patrol is known as going on duty to that event. You may occasionally switch patrols during your shift if your team structure changes. You must also leave a patrol by going off duty.

### Asset Database

Location information (for stops etc) gets downloaded from an Asset Database containing HASTUS location data to be able to use FEIMS in offline environments.

Before you commence a patrol, it is recommended that you obtain the latest offline asset database.

if you do not download the offline asset database, the app will function normally in online situations however you will not be able to issue notices, so if you do forget, then you can wait for network connectivity to be restored.

### RPS Activity

A Revenue Protection Service (RPS) Activity is a static patrols on a platform or station. Only one officer in a team needs to update the current activity, and it will update for all users in that patrol. The task of updating the activities throughout the patrol can be decided upon by the team and rotated throughout the shift as needed.

### Interaction

An Interaction represents each action with a customer by an officer.

Interactions are the way officers look up offenders, issue penalties and record incidents, and are a core part of the experience for Authorised Officers.

It includes:

* A guided smart form
* Evidence collection
* Customer details
* Infringement details
* Fines and Cautions

### Review

A review process allows interaction to be reviewed and cancelled.

This includes:

1. Self review — viewing and amending previously created interactions
2. Peer review — signing off on a partner’s interactions
3. Cancelling or downgrading a penalty notice

### Integration

The system supports modern integrations with other business systems including TRAILS, HASTUS and RM8.
{% endif %}

{% if visitor.claims.platforms.fcms === true %}

###

{% endif %}

{% if visitor.claims.platforms.trips === true %}

### TRIPS Modules

TRIPS consists of four main modules:

1. [Court ](broken://pages/88IQYxWUwu3bgB39d3En)- used mainly to handle prosecution matters&#x20;
2. [Officers](broken://pages/zhlzk5S6pnN2N29nIiNg) - used to manage officers, officer IDs and accredited transport operators
3. [Offenders](broken://pages/TYmvjTftnxCd63VqHB3T) - used to manage individual offenders, organisations and vehicles
4. [Compliance](broken://pages/WgyQHtFHMVPQq3DdvYyM) - used to manage infringements, warnings, coorespondence, enforcement and payments

There are several user levels that provide access to these modules.

### Record of Non-Compliance (RoNCs)

TRIPS uses Record of Non-Compliance (RoNCs) to record Infringements and Warnings. These are transcribed from officer records into the system via the Compliance module by administration staff.
{% endif %}

{% if visitor.claims.platforms.cw === true %}

### Contacts, Organisations and Workspaces <a href="#contacts-organisations-and-workspaces" id="contacts-organisations-and-workspaces"></a>

**Contacts** are records of individuals. You can link them to Organisations. Contacts may receive communications through the system in accordance with their communication preference. Users are specific types of Contacts with login access to the system.

**Organisations** (eg agencies, companies) are groups of related contacts. Contacts and Users can only be associated with a single Organisation.

You can also associate organisations with positions. Positions associated with Organisations provide special access to collaborate in their private **Workspaces**. This secures information and functions. It lets users go on duty and collaborate as a group. For example, they can access shared documents or accept assigned tasks.
{% endif %}

{% if  %}

### 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.
{% endif %}

{% if visitor.claims.platforms.cw === true %}

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

{% endif %}

{% if  %}

### 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.

{% if visitor.claims.platforms.cw === true %}

* **Cluster-Site** - a deployment where a single Site is used by multiple organisations with shared information each organisation is defined by a Region.

Neither of these configurations are common and beyond the initial testing and training, most are deployed with a single Site and Region.
{% endif %}
{% endif %}


---

# Agent Instructions: 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:

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

The question should be specific, self-contained, and written in natural language.
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.
