Core concepts in Ownself Gather
Overview
Ownself Gather is a DIY case management platform that enables public officers to centralise, track, and coordinate cases through configurable statuses until resolution. This page explains the core concepts that underpin the platform — what an app is, how cases flow through statuses, how the role model controls access, how cases enter the system, and how workflows automate actions.
Understanding these concepts is essential before configuring an app, as the relationships between apps, case types, statuses, roles, and workflows determine how cases are created, processed, and resolved.
What is an app?
An app is a self-contained case management system with its own database, users, roles, workflows, and configuration. Each app operates independently — users, cases, and settings in one app are not shared with another.
Apps serve as the top-level container in Ownself Gather. All configuration (case types, statuses, roles, workflows) exists within the scope of a single app. A single agency can have multiple apps for different use cases (for example, one app for translation requests and another for grant applications).
App lifecycle
An app has two states:
- Draft — the app is being configured and tested. A purple banner is displayed to all users.
- Published — the app is in operational use. Publishing unlocks the Reset App feature, which allows administrators to clear test data (cases, customers, users, reports, API keys, and workflows) before going live.
Publishing is a one-way signal to the Ownself Gather team that the app is in production use. There is no functional difference between Draft and Published beyond the availability of the reset feature.
Case lifecycle
A case is the central unit of work in Ownself Gather. Each case tracks an enquiry, request, application, or any item that moves through a defined set of statuses until resolution.
How cases move through statuses
The diagram above shows a typical case lifecycle. Key points:
- Every app has configurable statuses. The defaults are Open and Closed, but administrators can define any set of statuses that matches their workflow.
- Exactly one status is the default status — assigned automatically to all newly created cases.
- One or more statuses can be marked as final statuses. Cases in a final status may have restricted editing and deletion depending on role permissions.
- Status transitions are not restricted by default. Any user with edit permission can change a case to any status. For stricter control, administrators can enable role-based status transitions (an advanced feature), which defines per-role rules for which status changes are permitted.
Case duration and SLA tracking
Each case tracks a duration — the elapsed time since creation, measured in days. The duration counter runs continuously unless paused. Administrators can configure the case type to:
- Set a threshold (in days) that flags cases exceeding the limit.
- Exclude weekends and public holidays from the count (measuring working days instead of calendar days).
- Exclude ad-hoc days (additional non-counting days defined by the administrator).
Users and workflows can pause, resume, and reset the duration counter at the case level. This supports scenarios where cases are blocked by external dependencies and the SLA clock should not run.
The role model
Ownself Gather uses a role-based access control model. Every user in an app is assigned one or more roles, and each role has a defined set of permissions.
Default roles
Three roles are created with every new app:
- Admin — full access to all settings, configuration, user management, workflows, API keys, and audit logs. Can manage the app lifecycle (publish, reset, deactivate, delete).
- Manager — can view, create, edit, assign, and tag cases. Can view statistics and customers. Cannot manage app settings or users.
- User — can view, create, edit, and assign cases. Cannot export cases, view statistics, or access admin settings.
All three roles are fully customisable. Administrators can modify permissions, rename roles, delete roles, and create new ones.
Permission scoping
Case management permissions can be scoped along two dimensions:
- Case type — permissions can apply to all case types or to specific case types only.
- Case ownership — permissions can apply to all cases, only cases assigned to the user, only cases created by the user, or (with the advanced tags feature) only cases whose tags match the user’s tags.
This two-dimensional scoping enables granular access control without requiring separate apps.
Field-level permissions
Beyond case-level access, administrators can control visibility and editability of individual case fields per role and per case status. Each field can be set to:
- View and Edit — the user can see and modify the field.
- View only — the user can see but not modify the field.
- Hidden — the field is not visible to the user. Audit log entries for hidden fields are also hidden from that role.
How cases enter the system
Cases can be created from four sources:
1. Manual creation
Users with create permission can create cases directly within the app by selecting Create Case on the Cases page.
2. FormSG submissions
A FormSG form can be linked to a case type via webhook. Each form submission automatically creates a new case with the form fields mapped to case fields. This integration requires the form’s secret key and webhook URL.
Only single-respondent forms support direct webhook integration. Multi-respondent forms require Plumber as an intermediary.
3. Email correspondence
Each case type can have a unique email address (in the format correspondence+<app>+<id>@gather.gov.sg). When an agency’s generic mailbox auto-forwards emails to this address, each new email thread creates a new case. Subsequent emails in the same thread are added to the existing case’s correspondence.
Three email parsing mechanisms are available to automatically populate case fields from the email content: Paragraphs (field name on one line, value on the next), Line by line (field name and value separated by a colon on the same line), and HTML (structured HTML with data-field attributes).
4. API integration
External systems can create cases via the Case Management API (POST /cms/api/cases). Cases created via API have the case source displayed as API.
Instant and scheduled workflows
Workflows automate case management actions based on triggers and criteria.
Instant workflows
Instant workflows execute immediately when a trigger event occurs. Supported triggers include: case created, case status changed, case assigned, case field updated, case email received, case tagged, and case duplicated.
When a trigger fires, the workflow checks whether the case meets optional additional criteria (based on field values, status, tags, or other conditions) before executing its actions.
Scheduled workflows
Scheduled workflows run at regular intervals — daily, weekly, monthly, or on ad-hoc dates. They execute during off-peak hours (between 21:00 and 06:45) and process batches of cases matching the configured criteria.
Scheduled workflows can be scoped to cases from the previous day, week, or month, or to all cases. They can also target cases approaching or exceeding the duration threshold, enabling automated SLA monitoring and escalation.
Basic and advanced mode
- Basic mode provides a linear sequence of actions (auto-assign, change status, send email, update fields, update app variables, adjust duration, send webhook, generate report).
- Advanced mode adds if-else conditions, loops, and custom scripting for complex logic.
Workflows can be saved as drafts, deactivated (paused without deletion), duplicated across apps, and monitored via detailed execution logs.
Customer profiles and case aggregation
Ownself Gather optionally supports a customer layer that aggregates cases by a unique customer identifier (such as NRIC, email address, or UEN).
When enabled, cases sharing the same identifier value are grouped under a single customer profile. This provides a consolidated case history view per customer, allowing officers to see all interactions with a specific individual or organisation.
The customer profile displays fields from the most recently updated case. Customers can be searched, filtered, and managed from the Customers page.
Cross-product integrations
Ownself Gather integrates with several products in the Singapore government technology stack:
- FormSG — primary intake channel for case creation via form submissions.
- Plumber — extends Ownself Gather workflows for multi-respondent forms, secondary form syncing, hour/minute SLA tracking, and M365 Excel data enrichment.
- Opus — dedicated trigger and action nodes enable Opus workflows to create, update, search, and delete cases, upload files, and retrieve emails from Ownself Gather. Authenticated via API key.
- WOG AD / Singpass / TechPass / CorpPass — authentication methods for different user types.
