Skip to main content

Service Statuses

Service Statuses

Purpose and when to use this record

Define the controlled service-order states and the workflow group in which each state can be selected.

At a glance

  • Identify it by: Name.

  • Why care: Customer, equipment, scope, priority, technician availability, parts, labor, and status must stay aligned from intake through billing.

Before you begin

You need the Brisk storespermission for the action you are taking on service statusesstatuses. asIf parta ofCreate, theEdit, serviceor module.Delete This generated referencecontrol is awaitingabsent, workflowdo review.not work around it with another user’s account; ask an administrator to review your role.

Create a recordservice status

Brisk Service Statuses create screen displayed with fictional documentation-demo data.
The Service Statuses create screen in the Brisk documentation demo.

TheCreate evidencea packetservice identifiesstatus only when the viewexisting choices do not represent the policy or classification you need. Near-duplicate setup values split reporting and make later selection harder.

  1. Select the business context first.

  2. Enter the required identifying and operational values: Name.

  3. Review Group against the source locationdocument or approved setup decision.

  4. Save the service status, then confirm Name on its detail page before continuing.

After saving: Open Service Orders and confirm the service status appears with the intended label and availability. Keep the old value for thishistorical action.records Confirmwhen user-facingchanging stepsit beforewould approvingsplit or relabel prior reporting.

Delete a service status

Delete this page.service status only if it is an unused duplicate or setup mistake. Once other records refer to it, preserve that history and make the value inactive when the screen provides that option.

Before confirming, check for related Service Orders. Brisk may refuse deletion when another record depends on this one; resolve the duplicate or use the supported correction workflow instead of breaking the trail.

On the confirmation page, verify Name. After confirmation, return to the Service Statuses list and make sure only the intended service status was removed.

ViewReview recordservice status details

Brisk Service Statuses detail screen displayed with fictional documentation-demo data.
The Service Statuses detail screen in the Brisk documentation demo.

The evidence packet identifiesUse the viewdetail page as the shared record of what this service status currently means. Verify Name, and sourceGroup locationbefore relying on it for thisa action.decision.

Confirm

Compare user-facingthe stepsservice status with its source document or approved setup request before approvingdeciding that it needs correction.

Next check: Open Service Orders and confirm the service status appears with the intended label and availability. Keep the old value for historical records when changing it would split or relabel prior reporting.

Edit an existing service status

Edit this service status when the underlying policy or classification changed. First determine whether historical transactions should retain the old value; if so, deactivate the old choice and create a new one.

  1. Open the detail page. Compare Name with the supporting document or approved request.

  2. Recheck the identifying information shown on the screen. These values are most likely to change intake, estimating, dispatch, parts, labor, completion, and billing.

  3. Save the change, return to the list, and confirm that the service status now appears under the expected Name.

After the change: Open Service Orders and confirm the service status appears with the intended label and availability. Keep the old value for historical records when changing it would split or relabel prior reporting.

Find and review recordsservice statuses

Brisk Service Statuses list screen displayed with fictional documentation-demo data.
The Service Statuses list screen in the Brisk documentation demo.

The evidence packet identifiesUse the viewService Statuses list to find the correct record before opening or changing it. Compare Name. Compare the full identifier rather than relying on a similar name.

Open the service status whose Name match the task. If it is missing, clear the list filters and sourcerecheck locationthe identifying information shown on the screen rather than creating a replacement immediately.

Fields and business rules

Brisk stores 2 user-relevant fields for this action.service Confirmstatus, user-facingincluding steps0 beforelinked-record approvingselections and 0 controlled-choice fields. Create and edit screens may hide calculated or workflow-managed values from this page.full reference.

Editanexistingrecord

The

evidencetheviewandsourcelocation user-facingstepsbeforeapproving
Field Required What packetit identifiescontrols
NameYesHuman-readable name for this action.service Confirmstatus.
Group NoStatus group numbers determine when they are available for selection. Group 1 statuses are always visible, but Group 2 will only present on a ticket that has a Group 1 status, Group 3 will only present on Group 2, etc.

What happens next

Open Service Orders and confirm the service status appears with the intended label and availability. Keep the old value for historical records when changing it would split or relabel prior reporting.

Common mistakes and troubleshooting

  • The record will not save: Recheck Name and any message beside the field. A required related record may also be inactive or unavailable to your role.

  • The values look right but the result is wrong: Compare this page.

    service

    Deletestatus a record

    The evidence packet identifieswith the view and source locationdocument foror thisapproved action.setup Confirmdecision, user-facingthen stepscheck beforethe approvingdownstream thisscreen page.where it is used.