Introduction

Protrak Lifecycle Workflow

Configurable state management, promote actions, permissions, commands, automation, and integrations for governed business processes

Capability Positioning

Lifecycle Workflow governs how each business record progresses from one state to another. Administrators can configure states, allowed transitions, promote actions, role-based visibility, state-wise permissions, mandatory comments, commands, notifications, and program hooks so each process follows the right controls without custom screen development.

Capability Overview

The lifecycle capability is the foundation for process governance in Protrak. It is not limited to basic states such as Planned, In Progress, and Completed. Customers can model different workflows for different entity types, define what users can do in each state, decide which actions are visible or system-only, require comments or validations during transitions, and attach commands that update attributes, send notifications, unlink resources, execute C# programs, or synchronize parent-child records.

This makes lifecycle configuration suitable for operational execution, approvals, quality checks, field service, project tracking, exception handling, and automation-heavy processes.

Core Capabilities

Type-Specific Lifecycle Modeling

• Configure a separate lifecycle for each entity type such as project, task, ticket, process node, asset, audit, inspection, or service record.
• Define states that match the business process, including Planned, In Progress, On Hold, Under Review, Approved, Completed, Not Required, Disabled, Discarded, or customer-specific states.
• Allow parent and child records to follow independent lifecycles while automation keeps progress, status, and relationships synchronized.

Promote Actions and Transition Paths

• Define valid source-to-target transitions such as Initiate, Submit, Review, Approve, Reject, Hold, Resume, Complete, Skip, Discard, or Not Required.
• Control whether an action appears in the UI, is restricted by role, or is hidden for custom-program-only execution.
• Require comments, confirmation, or input dialogs during promotion when business justification or audit evidence is needed.

State-Wise Permissions and Access Control

• Configure permissions per state for editing basics, edit attributes, link instances, unlink instances, promote actions, and other record interactions.
• Allow different roles to have different rights in each state, such as operators updating comments while managers approve closure.
• Prevent unauthorized changes once a record reaches review, approval, completion, or locked states.

Promote Commands and Process Automation

• Attach commands to transitions to update attributes, copy user input to fields, unlink resources, send notifications, or execute program logic.
• Use C# program hooks for advanced scenarios such as completion roll-ups, dependency checks, cross-entity updates, or integration calls.
• Configure hidden actions such as Skip or Discard for background automation where users should not manually trigger the action.

Auditability and Operational Traceability

• Capture who performed a transition, when it happened, which comments were entered, and which commands were executed.
• Use lifecycle history to support customer communication, audit reviews, compliance evidence, and troubleshooting.
• Connect lifecycle state to dashboards, reports, search, activity history, and notification behavior.

Requirement-to-Configuration Mapping

Business requirement	Configuration approach	How it addresses the requirement
Different work types follow different processes	Assign separate lifecycles to each entity type and configure states per process.	Projects, tasks, tickets, audits, and process nodes can each follow the workflow they require.
Only managers should approve completion	Restrict the Complete or Approve promote action to the manager role in the relevant state.	Unauthorized users cannot perform controlled transitions.
Users must provide a reason before hold or rejection	Configure promote-action dialogs and mandatory comments.	The record history captures business justification for audit and review.
Resources should be released after completion	Attach an unlink-instances command to the transition to Completed or Discarded.	Operators, assets, or linked resources are automatically freed after the work ends.
Parent progress should update when child work closes	Attach a program command that recalculates parent completion when a child record is promoted.	Progress reporting stays accurate without manual parent updates.
Some actions should be automation-only	Configure promote actions as hidden or custom-program-only.	Background logic can execute cleanup or skip paths without exposing the action in the UI.

Configuration Model

1. Define the entity type and the lifecycle model required for that business process.
2. Create the state list, including the default starting state and terminal or exception states.
3. Configure promote actions from each source state to allow target states.
4. Set action visibility, role access, mandatory comments, and whether the action is UI-visible or automation-only.
5. Configure state-wise permissions for editing basics, editing custom attributes, linking, unlinking, and promotion.
6. Attach promote commands such as update attributes, send notifications, unlink instances, or execute C# programs.
7. Validate lifecycle behavior with sample records, including role access, comments, parent-child updates, notifications, and failure handling.

Use Cases and Scenarios

Use case	Scenario	Configuration outcome
Operational task lifecycle	A task moves from Planned to In Progress to Completed, with comments and role permissions at each transition.	Execution status is controlled and traceable.
Review and approval	A process node moves from Active to Under Review to Approved, with approval rights restricted to authorized roles.	Approvals follow a governed path and cannot skip review.
On Hold process	A record is moved to On Hold for a mandatory reason and later resumed by an authorized role.	Delays are visible and justified in history.
Parent-child roll-up	When child tasks are completed, a program updates the parent project completion percentage.	Project reporting stays current without manual calculation.
Resource cleanup	A promote command unlinks operators or resources when a task is completed or discarded.	Resources are released for future planning.
System-only skip/discard	Automation triggers hidden Skip or Discard actions when records are not required or invalid.	Workspaces stay clean without exposing sensitive actions.

Advanced Configuration Scenarios

State-Dependent User Experience

• Buttons, fields, forms, and available actions can change based on the record state and user role.
• A user may be able to edit comments in one state, view only in another, and approve only when assigned the correct role.

Commands as Transition Outcomes

• A single promote action can capture comments, update attributes, notify stakeholders, unlink resources, and run custom logic.
• This enables the transition to complete both the visible state change and the behind-the-scenes process obligations.

Parent-Child and Cross-Entity Automation

• Child task completion can update parent progress, while the parent state can remain independent.
• Related resources, assets, or process nodes can be linked or unlinked as the lifecycle progresses.
• Programs can enforce complex business rules that are not practical through simple configuration alone.

Failure Handling and Controlled Escalation

• If a command fails, the issue can be logged and selected failures can notify authoritative users.
• Not every failure needs a broad notification; escalation can be configured based on business importance.

Integration Touchpoints

• Notifications can be sent from promote commands, approval steps, hold/rejection actions, and command failures.
• Dynamic Forms can capture structured data before a record is submitted, approved, completed, rejected, or placed on hold.
• Job Scheduling can run lifecycle checks for overdue states, pending approvals, stale work, or automated transitions.
• Program commands can execute C# logic for calculations, cross-entity updates, validations, and enterprise integration calls.
• Reports, dashboards, search, audit history, and activity history can reflect lifecycle state, transition comments, command outcomes, and process progress.

Protrak provides various triggers to plugin custom code ("Programs") during various events in type instance lifecycle. Programs are a powerful way to customize Protrak with any business logic required by customer.

Programs are C# classes that implement interfaces as defined in the Protrak toolkit SDK.

Below pages explain the different program triggers and how to use them.

Child Pages

• PreCreate Trigger
• PostCreate Trigger
• PreConnect Trigger
• PostConnect Trigger
• PreDisconnect Trigger
• PostDisconnect Trigger
• PreUpdateRelation Trigger
• PostUpdateRelation Trigger
• PreUpdate Trigger
• PostUpdate Trigger
• PreDelete Trigger
• Promote Action
• Promote Action Command
• Schedular
• Report
• Common Program
• PreUploadInstanceAttachment Trigger
• PostUploadInstanceAttachment Trigger
• PreDeleteInstanceAttachment Trigger
• PostDeleteInstanceAttachment Trigger
• PreImport Trigger