Implementation Guide

Elker Platform: Configuration Data Model

A guide to the building blocks you configure when implementing on Elker, and how they fit together. This is a conceptual map for planning your setup, not a technical or API reference.

How to read this

Elker is built from a small set of configurable objects. The two that organise everything else are Case Types and Workflows:

A Case Type is a distinct way your organisation handles a category of cases, from intake through to resolution (for example Speak Up, Whistleblowing, Student Complaint). It's the container.
A Workflow is a named end-to-end journey a case follows within a Case Type. You assemble it from the building blocks: forms, attributes, task lists, automations, snapshots, sharing rules and status transitions.

This document introduces the Organisation and Case Types, then the Workflow that ties everything together, then a deep dive into each building block. At the centre of everything is the Organisation, your tenant: every object below lives inside it, and nothing is shared with other organisations.

The object map at a glance

A Case Type contains one or more Workflows. Each Workflow is an ordered chain of steps assembled from the building blocks configured on the Case Type.

A worked example

To make the concepts concrete, here's how a single Workflow for a "Speak Up" Case Type might play out across the life of one case. The top row is the journey the case takes; underneath each phase are the building blocks that do the work at that point.

One Workflow ("Speak Up: Bullying") across four phases. The same building blocks from the map above, arranged in the order a real case uses them.

2.Reporting & analytics

Everything above describes a single case. Separately, the structured data captured on every case (its Case Attributes, statuses, tags and timings) rolls up across all your cases to drive dashboards, charts and filters. This is how you see trends, volumes and SLAs at a glance.

Structured data from many cases rolls up into analytics.

In the product, that looks like a live dashboard. A sample:

An illustrative analytics dashboard. The actual charts and filters are driven by the data captured across your cases.

3.Organisation

Your entire Elker workspace. Everything you configure lives inside it, and data is fully isolated from every other organisation.

What you configure: name, subdomain (and optional custom domain), default timezone, branding (Elker-branded or white-labelled), primary colour, and global limits (such as how many cases a single reporter can submit). Single sign-on (SAML/Okta) is also set at this level.

Connects to: everything below.

4.Case Types

A Case Type is a distinct way your organisation handles a category of cases, from intake through to resolution (for example Speak Up, Whistleblowing, Student Complaint). It's the top-level container: each Case Type has its own routing, statuses, attributes, task groups, automations and investigation documents. Most organisations need one to three.

What you configure: the name, whether it's active, its default chat behaviour, and which staff can see it in analytics. The Workflows and building blocks below are all attached to the Case Type.

Connects to: Workflows (each Case Type holds one or more), and every building block below.

A Case Type is the container; Workflows (section 5) are the variations within it. If two case categories go to different teams, follow different steps, or need separate board reporting, they're two Case Types.

5.Workflows

A Workflow is a named end-to-end journey a case follows within a Case Type, from submission to resolution. It's the layer that ties the building blocks (detailed in the next section) into a coherent process. Rather than configuring automations, tasks and forms in isolation, you assemble them into an ordered chain that reads left-to-right like the real handling process.

A Workflow is built as a chain of steps, each one referencing a building block you've already configured:

Step	References	What it does in the journey
Automation	an Automation rule	The spine: routes, notifies, escalates. Every Workflow has at least one.
Dynamic Task List	a Dynamic Task List	Drops a checklist of actions onto the case.
Follow-up form	a Follow-up Form	Collects more structured detail later in the case.
Snapshot	a Snapshot Template	Generates a formal document from the case's data.
Sharing rule	a group or inbox	Auto-shares the case with the right people.
Status transition	a Status	Moves the case to the next stage.

So a typical Workflow chain looks like:

Initial Form (intake)→ Automation (route + notify)→ Dynamic Task List→ Follow-up form→ Snapshot→ Status: Closed

A single Case Type can hold several Workflows, one per distinct journey. The journey is defined by what happens to the case (routing, tasks, follow-ups, escalation), not by what triggered it. For example, a "Speak Up" Case Type might have separate Workflows for Bullying (routes to Wellbeing, mediation tasks), Discrimination (routes to D&I, formal investigation) and a high-severity escalation variant (adds Legal and an extra escalation task).

What you configure: name the Workflow, add its steps from a picker (linking existing building blocks or creating new ones inline), order them, and set it Active or Draft.

Pulls together: Initial / Follow-up Forms, Case Attributes, Dynamic Task Lists, Snapshot Templates, Automations, Statuses, Inboxes / Groups.

6.The building blocks

These are the pieces you configure on a Case Type. On their own they're just configuration; a Workflow (the previous section) is what wires them into an end-to-end journey.

6.1 Case Attributes

Structured fields attached to a case (for example "Department", "Severity" or "Location"). They can be text, number, date, Boolean, or list fields, and single, grouped, or repeatable. They're filled automatically (by forms or automations) or manually by case managers.

What you configure: the attribute name, its type, its options (for list types), and whether it's required.

List-type attributes are the backbone of analytics and filtering: they're what populate dashboards, charts and search filters. If you'll group, chart or filter something later, model it as a list attribute, not just a note.

6.2 Statuses

The lifecycle stages a case moves through (for example Triage → Formal Investigation → Closed). Each Case Type can have its own set, beyond the standard Open / In Progress / Closed.

What you configure: the status name, its order, and the description shown to reporters vs. staff.

6.3 Tags

Flexible labels for filtering and grouping cases. Unlike a status, a case can carry several tags.

What you configure: name, colour, and the context (case or survey) they apply to.

6.4 Initial Forms

The form a reporter completes to create a new case. On submission it creates the case record and populates the Case Attributes you've mapped. Used for the intake of whistleblowing, complaints, grievances, incidents, and so on. Intake forms are unlimited, you can have as many as you like feeding into the same handling path.

What you configure: the questions and their types, conditional logic and branching, which attributes each answer maps to, translations, and visibility.

6.5 Follow-up Forms

A follow-up form added to a case at any time after it exists. It uses the same builder as an Initial Form, can be completed by reporters, case managers or external third parties (witnesses, managers, HR), and can read existing attributes and write back to them on submission. Ideal for risk assessments, manager reviews, witness statements and follow-up requests.

What you configure: the questions and logic (as with Initial Forms), which attributes it reads and writes, and who can complete it. Submitting a Follow-up Form can trigger Tasks.

6.6 Dynamic Task Lists

A Task is a reminder or required action on a case, with a description, assignee, due date and status. A Dynamic Task List is a pre-built checklist of tasks that gets created together, used to standardise how a case is handled (for example an investigation checklist: "Acknowledge reporter", "Assign investigator", "Risk assessment").

What you configure: each task's title and description, how many days until it's due, whether it's required, and who it's assigned to. Tasks are created manually, or automatically when an attribute value is set or a Follow-up Form is submitted, which makes them ideal for enforcing SLAs.

6.7 Snapshot Templates

A Snapshot is a document-style output (investigation report, case summary, letter, regulatory output) generated from a template, ranging from a fully structured layout to a blank Word-style document with track changes. A Snapshot Template can auto-populate variables from Case Attributes, so formal documents quote the case's own data.

What you configure: the template's structure and which Case Attributes map to which variables. Snapshots are then created and edited by case managers, versioned, and exported or shared.

6.8 Automations

The rules that make Elker act on its own. Automations are detailed in their own right because every Workflow's "moving parts" are automations: see section 7. In short, each is a WHEN (trigger) → IF (optional conditions) → THEN (action) rule. Actions include notify, change status, create tasks, auto-share, and send webhook.

Two more things that live on the case, captured by case managers rather than pre-configured: Case Notes (lightweight, timestamped, internal-only text, for call notes and observations, not structured for analytics) and File Uploads (evidence and documents, each set as internal-only or shared with the reporter at upload time).

7.Automations in detail

Automations are the rules that make Elker act on its own when something happens. Each automation has three parts:

WHEN a trigger event occurs

IF conditions match (optional)

THEN an action runs

The Trigger (WHEN)

The event that starts the rule. Available triggers include:

A case is submitted, closed or deleted
A case's status changes or a field is updated
An assignee is added or removed
A case has been idle for too long
A new case lands in an inbox
A task is due or completed
A message goes unread
A signal match is found, or an extended response is submitted

The Conditions (IF), optional

Narrow the rule to only certain cases. You can match on:

Case Type or Initial Form
Status or target Inbox
Assigned profile, a specific assignee, or the assignee's role
A Case Attribute value

Conditions are how you say "only for Whistleblowing cases" or "only when the attribute Severity = High".

The Action (THEN)

What the automation does. Each automation performs one action type:

Action	What it does
Send notification	Notify staff (configurable title, message, subject, button).
Change status	Move the case to a target status automatically.
Create task	Add a task (title, description, due date, assignees, category).
Auto-share	Share the case with specific staff at a given access level.
Send webhook	Call an external URL, for integrating Elker with other systems.

Example automations you might build:

When a case is idle for 7 days → send notification to the assignee.
When status changes to "Actioned" if case type is "Safeguarding" → create task "Manager sign-off".
When a case is submitted if field Severity = High → change status to "Urgent Review" (and, as a second automation, send webhook to your case-management system).

Each automation runs one action. To do several things off the same trigger, create several automations with the same trigger and conditions, or chain them as steps in a Workflow (section 5).

Connects to: Case Types, Initial / Follow-up Forms, Statuses, Inboxes, Case Attributes, Staff Contacts, Tasks, and Workflows (as steps).

8.People & access

8.1 Staff Contacts

The internal people who receive, manage and respond to cases.

What you configure: name, email, position/title, language, photo, and an out-of-office state. Each staff contact is given one or more Roles and assigned to one or more Inboxes.

8.2 Groups

A named team of staff contacts (for example "HR Team" or "Safeguarding"). Used to assign or notify several people at once rather than naming them individually.

What you configure: the group's name and its members.

8.3 Roles

Defines what a person is allowed to do. Each role is a bundle of permissions (such as view cases, manage analytics, edit forms, or remove cases). Elker ships with sensible default roles (Owner, Admin, Analyst, Contact, Survey) and you can create your own.

What you configure: the role's name and which permissions it grants. You then assign roles to staff contacts.

The Owner role is special: some powerful permissions, like editing reporting forms, are reserved for it.

8.4 Inboxes

Where cases arrive and where responsibility sits. An inbox is either a single named person or a team that several staff contacts belong to.

What you configure: name, contact details (email/phone), a greeting message shown to reporters, whether its contact details are visible to reporters, and its members. A Workflow's routing step sends new cases to a default inbox.

Connects to: Staff Contacts / Groups (members), Workflows (a routing step sends cases here).

9.Suggested implementation order

Build from the outside in: people and access first, then each Case Type and its building blocks, then assemble the Workflows that tie them together.

Organisation: branding, timezone, domains, SSO, limits.
Roles: confirm defaults or define custom roles.
Staff Contacts & Groups: add your people, assign roles.
Inboxes: create the destinations, add members.
Case Types: define each distinct handling process.
Case Attributes, Statuses, Tags: attach them to each Case Type.
Initial & Follow-up Forms: build intake first, then follow-up forms, with logic and translations.
Dynamic Task Lists & Snapshot Templates: the checklists and documents a journey will use.
Automations: the routing, notification and escalation rules.
Workflows: assemble the building blocks into named end-to-end journeys, one per distinct handling path. This is where it all comes together.