Taskr (Work Orders)

Part of the IP4CMS portal. ← All module guides

What it's for — Taskr is IP4CMS's field-task and work-order capability. It lets your team capture pieces of work, give them a clear status, assign them to the people (or teams) who will do them, track how far along each one is, and break large jobs down into smaller sub-tasks. In IP4CMS, Taskr is delivered in two connected ways: as work orders / tasks managed inside the portal (the project-and-task data your operators create and update day to day), and as a link to the external TaskR platform (Rekode), where field execution — the jobs your technicians actually pick up and complete in the field — happens. The portal side is your control room; the TaskR platform is where field crews run their work.

Where to find it

There are two distinct entry points, and which ones you see depends on your licence:

• TaskR module area — the standalone Taskr landing page, available when the taskr licence module is enabled. It is the front door to TaskR product features.
• Settings → Flows → TaskR integration — at Settings → Flows → TaskR integration. This is where you connect the portal to the external TaskR (Rekode) platform. It needs the separate flows:taskr licence module.

Day-to-day work-order data (the tasks, statuses, and assignments themselves) lives within the portal's Projects area, under the project module those tasks belong to. Each task is created inside a project module, so you reach your work orders by opening the relevant project.

Before you start

Check the following before you expect Taskr to work:

• Licences. The product features need the taskr module on your tenant licence. The platform connection (API and webhooks) needs the separate flows:taskr module. These are independent — you can have one without the other. If flows:taskr is off, the TaskR landing page shows an amber notice telling you the platform integration is not enabled.
• Permissions. You need the right permissions for what you want to do (see Permissions & access below). Without flows:taskr:integration:read you cannot even view the integration settings; without flows:taskr:integration:manage you can view but not change them.
• Platform credentials. To wire up the external TaskR platform you'll need its base URL and an API key, and optionally a webhook signing secret. Your TaskR/Rekode workspace must already exist (it is usually created during provisioning).

Key tasks

Task: Connect the portal to the TaskR platform

This is the one-time setup that lets the portal talk to TaskR (Rekode).

1. Open Settings → Flows → TaskR integration.
2. If you see an amber banner saying to enable flows:taskr, stop — the licence module is off and the form will not appear. Have it added to your tenant licence first.
3. Fill in the fields below and click Save. A green confirmation appears on success.

Fields

These values are stored as flows module settings (taskr_platform_base_url, taskr_api_key, taskr_webhook_secret). If you only have read permission the form loads but is locked and the Save button is hidden.

Task: Create a work order (task)

Work orders are created as tasks inside a project module.

1. Open the project module the work belongs to (under Projects).
2. Create a new task.
3. Complete the fields below and save. New tasks default to 0% complete.

Fields

Task: Assign a work order to people

Assignees are the people (or teams) responsible for the work. Taskr uses a flexible "assignable" model — an assignee can be a portal user or another assignable entity — so you are not limited to individual staff accounts.

1. Open the task.
2. Add one or more assignees, or replace the whole set at once.
3. Save.

How it behaves

• Add attaches one assignee; adding the same one twice is harmless (duplicates are ignored).
• Set replaces every existing assignee with the new list in a single action — useful for reassigning a job wholesale.
• Remove detaches a single assignee.
• For assignees that are portal users, their profile picture is shown alongside the task; other assignable types appear by name only.

Task: Move a work order through its lifecycle (statuses)

Statuses are how a work order shows where it is — for example New, In progress, Done. They are defined per tenant, so your set of statuses is whatever your organisation has configured.

1. Open the project area's task-status settings to review or create statuses.
2. To progress a work order, open the task and change its Status.

Status fields

Statuses are soft-deleted, so removing one keeps historical tasks intact.

Task: Track progress and roll-ups

Each work order carries a percent complete. When a task has sub-tasks, Taskr ignores the parent's own figure and instead shows an effective percent complete that averages the progress of its sub-tasks (recursively, all the way down). So if you split a job into five steps and three are done, the parent reflects the real combined progress automatically — you don't update the parent by hand.

Task: Provision or manage a TaskR (field execution) workspace

Field execution — the jobs your crews actually run — happens on the external TaskR platform. A TaskR workspace is created through IP4CMS provisioning rather than typed in manually. During provisioning you supply:

• Workspace / organisation name — the trading name of the TaskR workspace.
• Administrator email — the primary login for the workspace admin.
• Contact phone — optional onboarding contact.
• Data region — South Africa, West Europe, or West US. This decides which regional TaskR host stores your data; South Africa is the default.

Once provisioned you can also suspend and later reactivate a workspace from the same provisioning action. After onboarding completes you receive a login URL for the new workspace. The workspace ships with the standard TaskR modules — jobs, settings, and dashboards — which is where field staff pick up and complete work.

How the data connects

• Tasks live inside project modules. Every work order belongs to a project module, and project modules belong to projects. This is how a job is scoped to a particular piece of work or a particular customer/location context.
• Statuses, tasks, and assignees are three linked pieces. A task points at one status; a task can have many assignees; statuses and tasks are independent records you manage separately.
• Assignees connect to members and other entities. Assignment goes through a generic "assignable" — a portal user, or another entity type — rather than only individual staff. That is what lets you point a work order at the right responsible party, including people drawn from your members/contacts data.
• The portal and the TaskR platform are joined through Flows. The flows:taskr integration stores the platform URL, API key, and webhook secret as Flows settings. Flows is the bridge that carries information between the portal's work-order records and the external TaskR platform where field execution happens. Provisioning (Rekode) is what creates the workspace those flows talk to, and the chosen data region determines which regional host is used.
• Sub-tasks form a tree. A parent task and its sub-tasks roll up automatically, so the structure of the work (job → steps) is mirrored in the data and in the progress figures.

Permissions & access

The two integration permissions are gated on the flows:taskr licence module; the two taskr:* permissions are gated on the taskr module. If the licence module is off, the matching permissions have no effect.

Tips & gotchas

• Two modules, two purposes. taskr is the product module; flows:taskr is the platform integration module. Enabling one does not enable the other. If the TaskR area looks empty or the integration form refuses to appear, check which module is actually licensed.
• The integration form silently locks for read-only users. With flows:taskr:integration:read but not :manage, the form still loads and shows current values — but every field is disabled and there is no Save button. That is expected, not a bug.
• Secrets are masked, not hidden. The API key and webhook secret render as password fields. Re-entering them overwrites the stored value; leaving them as loaded keeps the existing one.
• Parent progress is automatic. Don't try to keep a parent task's percentage in sync by hand — once it has sub-tasks, its displayed progress is the average of theirs. Edit the sub-tasks.
• "Closed" is a status flag, not a delete. Mark finished states with Is closed rather than deleting the status. Deleting tasks and statuses is a soft delete, so records aren't truly lost, but reusing a status across history is cleaner.
• Region is set at provisioning time. The TaskR workspace's data region (and therefore which regional host holds the data) is chosen when the workspace is provisioned. Pick it deliberately — it determines data residency.
• Percent is clamped. Any progress value is forced into 0–100, so you can't accidentally store 150%.