Set up Tasks

Tasks separates configuration from operational work. A configurator defines the forms, permissions and Queue rules; a Worker receives and performs tasks. The same person can hold both responsibilities, but each needs its own grants.

Prepare the workspace

1. Open the Tasks administration page made available by your administrator. Enable Tasks and inspect Readiness. Enabling Tasks preserves existing settings and does not automatically enable or configure Work Schedule.
2. Ensure Work Schedule is enabled and its Worker identity capability is ready. Workers who receive or perform tasks need an active Worker linked to an active User. Standalone work does not require a complete shift calendar. Queues that consider working time need the corresponding schedule facts.
3. Use Security mappings to grant Configuration Management to the workspace roles that maintain Definitions, Queues and Worker Profiles. Runtime administration, creation and observation are configured separately.
4. Use Runtime Menu to add Tasks navigation to a selected user-defined menu. Existing placement and restrictions are preserved. A visible link does not grant permission, and configuration access does not make every task visible.

Do not create a second Worker for the same user to work around a missing grant. Correct the association, admission or role mapping that the diagnostic identifies.

Configure one usable Definition

Follow Task Definitions to choose Direct or Queue mode, define the data, select permitted participants and set the completion rules. Mode is immutable; choose it before creating real work.

For a small first flow, keep the data schemas empty, make the due date optional and leave Context optional. Configure Creator and the intended participant admissions explicitly. Check the available transitions and an active Outcome before asking a Worker to execute the task. Empty Parts are valid; they can later receive fields and layouts without introducing a second Task type system.

For Queue mode, also configure Queues and Workers. An active Queue must admit the Definition. Pool membership, dispatcher mappings and Definition permissions solve different access questions.

Verify the flow with the intended users

1. As a Creator, create a task. Select the admitted participants and, for Queue work, the destination Queue. Save and reopen the result.
2. As the intended Worker, find the task in My work, or receive it using the Queue’s acquisition action. Confirm that a separate observer sees only what their configured rights allow.
3. Start, record Working Data if required, then complete with an allowed Outcome. Confirm that History records the changes and that Done offers no Start action.
4. If using Collaboration or Instructions, check them as that Worker. Access to the Task does not imply unrestricted access to Context records or File Storage.

Use troubleshooting when an action is unavailable. Configure signals and notifications after the basic working flow is usable. A due badge alone does not configure pre-deadline warnings, recipients or acknowledgement.

Change configuration deliberately

Open work uses current Definition and Queue policy. New defaults do not rewrite saved Task values. Changing admissions, role mappings or capacity does not silently unassign people; an authorized operational action handles existing work. Lowering a limit can leave existing work over the limit while preventing a new increase. Completion history remains a record of the actual completed action.

Disabling Tasks preserves configuration and data. Deactivation and deletion of individual configuration records have their own dependency checks. Review the reported dependency instead of assuming that an inactive record can be deleted.

For C# configuration, use Tasks configuration automation. For direct HTTP configuration, use the installation’s /openapi/moltaro-config-v1.json; operational Task commands and reads are in /openapi/moltaro-public-v1.json. Both describe the same services used by the UI.