Service Request Statuses
Service Request Statuses are the catalog of steps a Service Request moves through from creation to closing (for example: New, Assigned, In Progress, Closed). Each status defines what color it's shown in, whether it closes the request, who becomes responsible for it when it enters that status, and which users are allowed to move a request into it. This lets you control your service team's workflow instead of relying on informal conventions.
What is it and what is it for?
Each record represents a possible status for a Service Request. AdmCloud ships with predefined native statuses (the first 1000 IDs), which can't be deleted and whose name can't be changed, but you can add as many additional statuses as your workflow needs (for example, "Waiting for Part" or "Pending Customer Approval").
This catalog is the foundation of the Service Request Workflow (Document Status Workflows), which defines the allowed order to move from one status to another. That's why a status already used in a workflow, or set as the default status of a relationship (customer/consultant), can't be deleted.
How to use it
- Open the "Service Request Statuses" catalog, where you'll see every existing status with its Subsidiary (if applicable), its Status Label, a swatch of the assigned Color, whether it's Active or Inactive, and whether it's a "Native Status" of the system. The Color column shows only the swatch: when the status has no color, the swatch appears crossed out.
- Create a new status with the New button, entering at least its Name.
- Set the Assignment Type: when a Service Request changes to this status, the responsible person updates according to this rule (no change, the request's own customer/consultant, that consultant's supervisor, the last person assigned to this status, or a fixed default person you choose).
- Flag whether the status Closes the request, so Service Requests in this status count as completed in your reports and boards.
- Configure Customer Portal visibility: you can hide the status from the Portal, show a different name and note than the ones your internal team sees, and turn on a notification to the customer when their request enters this status.
- Assign a color with the color picker, which opens your browser's palette. That color is used as the background of the status label on the Service Request lists and on the Customer Portal. If you'd rather leave the status without a color, click No color. Also set the expected Average Standard Days for this status, used on the Service Request Efficiency report.
- Pick the authorized users allowed to move a Service Request into this status, in the "Users" section of the detail view. If you don't select any user, the status is open to everyone.
- Save the record. The new status is immediately available for use on Service Requests and on any Status Workflow that includes it.
Key capabilities
- Predefined native statuses shipped by AdmCloud (can't be deleted; their name can't be changed).
- Unlimited custom statuses, tailored to your service team's workflow.
- Automatic assignment of the responsible person when entering each status (relationship, supervisor, last assigned, or a fixed default).
- "Closes" flag to mark which statuses count as the request being finished.
- Visibility control and custom text for the Customer Portal, with an optional notification to the customer on status change.
- Per-user restriction of who can move a request into each status, useful for enforcing approvals or role-exclusive steps.
- Expected Average Standard Days per status, used on the Service Request Efficiency report.
- Identifying color per status, chosen with a color picker. It is used everywhere a request status is shown: lists, the request detail, the status change history, the summary by status, the boards and the Customer Portal.
- Integrity protection: a status in use inside a Service Request Workflow, or set as a relationship's default status, can't be deleted.
- If your company uses Subsidiaries, each status can be limited to one specific Subsidiary (or left blank to be available for all).
Key fields
| Field | What it's for |
|---|---|
| Name | Identifies the status (for example, "In Progress"). Required, up to 200 characters. Can't be changed on native statuses. |
| Subsidiary | Limits the status to a specific Subsidiary; left blank, it's available for all. |
| Closes | Marks that reaching this status means the Service Request is considered closed/completed. |
| Assignment Type | Rule for updating the responsible person when a request changes to this status: no change, the request's consultant, that consultant's supervisor, the last person assigned to this status (or the default one if there's no prior assignment), or always a fixed default person. |
| Default Assigned To | User assigned when the Assignment Type requires it. Required only for those two types; must be left empty for the others. |
| Color | Color used to identify the status. You pick it with the browser's color picker and it becomes the background of the status label on the Service Request lists, the Customer Portal and the boards. It is optional: with the "No color" button the status is shown with the default neutral color. |
| Average Standard Days | How many days a request should, on average, stay in this status; used on the Service Request Efficiency report. |
| Don't Show in Customer Portal | Hides this status from customers checking their requests through the Customer Portal. |
| Send Customer Notification | Turns on the notice sent to the customer when their Service Request changes to this status. |
| Visible Description in the Portal | Alternate name the customer sees in the Portal, different from the internal status name. |
| Visible Notes in the Portal | Extra text the customer sees in the Portal while their request is in this status. |
| Notes | Internal remarks about the status, not visible to the customer. |
| Users | List of users authorized to move a Service Request into this status. If left empty, any user with access can do it. |
Validations on save
- Name is required.
- No other status can have the same Name.
- If Assignment Type is "Default Assigned To" or "Last Assigned (or Default)", the Default Assigned To field is required.
- For any other Assignment Type, the Default Assigned To field must be left empty.
- On native statuses (ID 1000 or lower), the Name can't be changed.
- A native status can't be deleted.
- A status can't be deleted while it's included in a Service Request Workflow.
- A status can't be deleted while it's set as the default status of a relationship (customer/consultant).
Availability
- Browsing, creating, editing and deleting Service Request Statuses requires the "Configuration" permission (System Administration module) on your user group.
- This catalog, and Service Requests in general, are only available on the Enterprise plan, and only if your company has the Service module turned on.
- If your company uses Service Request Workflows (Document Status Workflows) to enforce an order between statuses, that feature also needs to be turned on separately within the Enterprise plan.
Tips and common mistakes
Use "Last Assigned (or Default)" for recurring follow-up statuses. That way, if a request comes back to a status a consultant already worked on, it's automatically reassigned to them instead of losing track of the case.
Restrict sensitive statuses with "Users" (for example, a closing or warranty approval status) so only a specific group on your team can move requests into it.
A status in use can't be deleted. If you need to retire a status that's already part of a Service Request Workflow or is the default status for a customer or consultant, remove it from those references first; otherwise mark it as Inactive instead of trying to delete it.