My continONlifecycle
My Requests
How do employees raise requests that actually move through an approval workflow?
Requests in My continON run on the platform’s process engine: each request type is a workflow the organization has designed, and a submitted request advances through its states with history retained. The employee sees their own requests and where each one stands.
How it works
A request is a business-process instance, not an email: submitting one creates a workflow instance that advances through configured states, notifies the right actors — resolved by position, not by name — and keeps its activity history. The request list in the workspace shows the employee’s submissions with their current state.
Because request types are configuration, the catalog is the organization’s own: whatever processes are published as requests — with their forms, approvers, and generated documents — appear here. Leave has its dedicated screens as well, and both roads lead to recorded approvals rather than inbox threads.
What the record holds at once
Held constantMy Requests 4 states, at the same time
Workflow-backed requests
Each submission is a process instance with states, actors, and retained history.
Actors by position
Approvers resolve from the org model — initiator’s supervisor, head of unit, named position groups.
A catalog you define
Request types are processes the organization designs and publishes, with their own forms.
Status without asking
The employee’s request list shows the current state of every submission.
What this touches
See my requests running in continON.
A guided walkthrough on a sanitized demo tenant — this capability inside its module, on the shared platform.