Request Lifecycle
Every request in Nembl follows a lifecycle from submission to completion. Understanding the states and how requests flow through the system helps you know what to expect when you submit or process a request.
Request States
A request moves through these states during its lifecycle:
Open
The request has been submitted and is being actively worked on. This is the default state after submission. The request may be sitting in an inbox waiting for triage, moving through a workflow, or being worked on by an assigned team member.
Completed
The request has been fulfilled. All tasks are done, the workflow has finished, and the work is delivered. Completed requests remain visible in your history for reference.
Rejected
The request was reviewed and could not be accepted. This might happen because the request does not meet acceptance criteria, the information provided is insufficient, or the service is not the right fit. When a request is rejected, the requester receives a notification with an explanation.
Cancelled
The requester decided the request is no longer needed and cancelled it before completion. Any in-progress tasks are stopped and the workflow is terminated.
How Requests Flow Through the System
Here is the typical journey of a request:
1. Submission
A user selects a service and offering from the catalog, fills out the intake form, and submits the request. The request is created in the Open state.
2. Inbox Triage
The request arrives in the service inbox. Depending on the inbox's intake mode, one of three things happens:
- Manual — A person reviews the request and decides to accept, reject, or forward it.
- Workflow — The linked workflow starts automatically and routes the request based on its rules.
- Agent — An AI agent evaluates the request, validates the inputs, and recommends an action (accept, reject, or route).
3. Workflow Processing
If a workflow is linked to the offering, it guides the request through a series of phases. Each phase represents a step in the process, such as approval, assignment, or data collection. The workflow can:
- Route the request to a specific team or individual.
- Create tasks and assign them to people.
- Wait for approvals before proceeding.
- Fork into parallel paths for work that can happen simultaneously.
- Make decisions based on request data to choose different paths.
4. Task Execution
As the request moves through the workflow, tasks are created and assigned to team members. Each task appears in the assignee's personal inbox. Tasks represent the actual work that needs to be done, like reviewing a document, configuring a system, or approving a purchase.
5. Completion
When all tasks are done and the workflow reaches its end phase, the request moves to the Completed state. The requester is notified that their request has been fulfilled.
Multi-Queue Visibility
One of Nembl's distinctive features is that a single request can appear in multiple inboxes at the same time, with different status in each. For example:
- In the Service inbox — Status: Forwarded (it has been sent to a team)
- In the Team inbox — Status: In Progress (the team is working on it)
- In an Individual's inbox — Status: Assigned (waiting for the person to start)
This means a service manager can always see the status of all their service's requests, even after they have been routed to teams. The request is a single record with a unified identity, but its status varies depending on which inbox you are viewing it from.
Request Timeline
Every request has a timeline that records everything that has happened:
- When it was submitted and by whom
- When it entered each inbox
- When it was accepted, rejected, or forwarded
- When workflow phases started and completed
- When tasks were created, assigned, and completed
- Comments and notes added along the way
The timeline gives you a complete audit trail of the request's history. See Tracking Requests for details on how to follow your requests.