Workflows are a configurable system for processing jobs in structured queues. They allow account administrators to define repeatable processes — such as diligence reviews, quality checks, or closeout procedures — and route matching jobs into queues for users to work through one at a time.
- Overview
- Creating a Workflow
- Assignment Rules
- Guidelines (Attempt Requirements)
- Job Elements
- Workflow Actions
- Form Buttons
- Completion Settings
- Dashboard Integration
- Working Through a Workflow
- How Jobs Get Assigned to Workflows
A workflow defines:
- Which jobs should enter the workflow (via assignment rules)
- What the user sees while reviewing each job (via job elements)
- What the user can do while reviewing each job (via workflow actions)
- When the job is done in the workflow (via completion settings)
Once configured and set to "Active", the workflow becomes available. Jobs matching the assignment rules are automatically added to the workflow's queue. Users can then work through the queue, reviewing and acting on one job at a time.
Navigate to Job Workflows from the main menu and click New Workflow.
| Field | Description |
|---|---|
| Name | A descriptive name for the workflow (e.g., "SOP Diligence Review", "Pending Closeout QC") |
| Status | Draft — the workflow is being configured and is not visible in dashboard queues. Active — the workflow is published and visible to users. |
| Associated Job Types | Scope the workflow to specific job types (e.g., SOP, pFiling). If none are selected, the workflow applies to all job types. |
Assignment rules determine which jobs are automatically added to the workflow. Each rule defines criteria that a job must match, along with timing and rate controls.
A workflow can have multiple rules. Each rule is evaluated independently — a job only needs to match one rule to be included in the workflow (rules are OR). However, within a single rule, all selected criteria must match (criteria are AND). For example, if a rule requires both "Served" status and "Rush" priority, the job must be both served and rush to match that rule.
| Setting | Description |
|---|---|
| Name | A label for the rule (e.g., "Non-Service Jobs", "Rush SOP Jobs"). Used for internal reference. |
| Assignment Rate | Controls what fraction of matching jobs enter the workflow. "Every job (100%)" means all matching jobs are included. "Every 4th job (25%)" means roughly 1 in 4 matching jobs is included. This uses a Redis counter to track how many jobs have matched the rule. |
| Dashboard Queue Link | Links this rule to a specific dashboard chart segment. When set, clicking that chart segment on the fulfillment dashboard will show an "Enter Workflow" button that links directly into this workflow. See Dashboard Queue Linking. |
Each rule has two timing options:
- On job creation — The rule is evaluated when a new job is created. Use this for criteria like document type that are known at creation time.
- On job update — The rule is evaluated when a job's criteria fields change. Use this for criteria like job status that change over time.
You can enable both if needed.
Criteria are the filters that determine if a job matches the rule. All selected criteria within a single rule act as AND conditions — the job must match every criterion.
| Criterion | Description |
|---|---|
| Job Status | The job's current status (e.g., "Served", "Non-Service", "Pending"). Multi-select. |
| Service Status | The service of process status. |
| Service Type | The type of service attempt on the job (e.g., "Personal Service", "Substituted Service"). Checks if the job has at least one attempt of the selected type. Multi-select. |
| Document Type | The document type(s) on the service of process. Checks both the primary document type and the document type collection. Multi-select. |
| Job Source | Where the job originated from (e.g., API source, batch upload, ServerHub). Multi-select. |
| Mailing Status | The mailing state of the job — whether mailing is required, already mailed, or not required. Multi-select. |
| Priority | Whether the job is Rush or Routine (based on the service of process rush field). Multi-select. |
| Case Type | The case type on the service of process. Multi-select. |
| Workflow Type | The workflow type on the service of process (this is a classification field on the SOP, distinct from the workflow feature itself). Multi-select. |
| Exclusivity | Checkbox: "Only assign if the job is not in another active workflow." When enabled, a job will be skipped during assignment if it's currently assigned to any other workflow where it hasn't been completed yet. Once the job completes in those other workflows, it's automatically re-evaluated and can then be assigned. See Re-evaluation After Workflow Completion. |
| Due Date | Filters the workflow queue view by due date. Options: Due Today, Before Today (Overdue), After Today. Note: this filter applies to the queue view only and does not affect which jobs get assigned to the workflow. |
Guidelines define what a job should have before it can be considered properly completed. They appear as a checklist in the workflow view with visual checkmarks indicating which are met. Guidelines are informational — they do not block the user from submitting the workflow.
| Setting | Description |
|---|---|
| Number of Attempts | How many qualifying attempts the job should have (e.g., "3 attempts"). |
| Days | What days the attempts should occur on: Any Day, Weekdays, Weekends, or Different Days. "Different Days" requires each counted attempt to be on a separate calendar date. |
| Timing | Time-of-day requirements. You can set a "between" window (e.g., 6:00 AM - 9:00 AM), an "after" time, or a "before" time. All times are evaluated in the attempt's local timezone. |
Guidelines can be scoped to specific job characteristics so that different jobs see different guidelines:
| Condition | Description |
|---|---|
| Counties | Only apply this guideline to jobs in specific counties (based on the court's county). |
| Recipient Type | Only apply to individual or organization recipients. |
| Job Sources | Only apply to jobs from specific sources. |
| Address Labels | Only apply to jobs with specific service address labels (e.g., "Business", "Residence"). |
If no conditions are set, the guideline applies to all jobs.
Each guideline has a "Visible on job page" checkbox. When enabled, the guideline also appears in a "Guidelines" section on the job's sidebar outside of the workflow. This is useful for process servers viewing the job in the field who need to know the attempt requirements.
Job elements control what job information is visible in the workflow sidebar while the user is reviewing a job. The sidebar appears to the right of the workflow form.
Available elements:
| Element | What It Shows |
|---|---|
| Job Info | Party to serve, address type, client/server info, and the full job sidebar details (expandable). |
| Attempts | A list of all attempts on the job. |
| Affidavits | The job's affidavit documents. |
| Invoices | The job's invoice(s). |
| Uploads | Files attached to the job. |
| Notes | Notes/events on the job. |
| Tasks | Tasks associated with the job. |
| Activity | The job's activity feed / audit trail. |
At least one job element should be selected so the user has context while completing the workflow.
Workflow actions define what the user can do while reviewing each job. These appear in the main content area (left side) of the workflow view. Each action is an independent toggle — enable only the ones relevant to your process.
(Staff-only setting — visible only to internal staff in the workflow builder)
When enabled, the standard diligence review form is included in the workflow. This provides:
- Rating Score — a quality rating for the job
- Reject Reason — why the job is being rejected (if applicable)
- Non-Service Category — categorization for non-service outcomes
- Comments — free-text notes about the review
- Set Out for Service checkbox — option to change the job status back to "Out for Service"
Custom form fields let you build a structured form that users fill out when completing the workflow. Responses are saved with the workflow submission record.
Supported field types:
| Type | Description |
|---|---|
| Text | Single-line text input |
| Textarea | Multi-line text input |
| Select | Dropdown with predefined options (comma-separated values) |
| Checkbox | A single checkbox (true/false) |
| Radio | Radio button group with predefined options (comma-separated values) |
| Date | Date picker |
| Number | Numeric input |
Each field has:
- A label (the field name shown to the user)
- Optional options (for select, checkbox, and radio types — enter comma-separated values)
- A required flag (if checked, the user must fill in this field to submit the workflow)
Custom fields can be reordered by position and added/removed dynamically.
When enabled, the user can edit specific parts of the job directly from the workflow form. You select which sections are editable:
| Choice | What's Editable |
|---|---|
| Job Type | The job type selection and documents to be served |
| Client Info | Client company information |
| Court Info | Court case details and hearing information |
| Recipients | Recipient name, address, and description fields |
| Addresses | Registered agent information |
| Server | Process server company assignment |
| Instructions | Job status and special instructions |
| Fees | Pricing fields (internal feature accounts only) |
Edits are saved to the job when the user clicks the primary or secondary action button. The same permission checks that apply in the normal job edit form also apply here.
When enabled, the user can create or edit invoices directly within the workflow. An embedded invoice editor opens inline — no need to navigate away. If the job already has an invoice, the user sees an "Edit Invoice" button; otherwise, they see "Create Invoice".
When enabled, the user can create affidavits within the workflow. You configure which affidavit templates are available — if none are selected, all of the account's templates are available. The affidavit editor opens inline via an embedded frame.
When enabled, a file upload section appears allowing the user to attach files to the job without leaving the workflow. Any existing uploads on the job are also displayed.
When enabled, the user can send a note using pre-configured templates. You select which note templates are available in the workflow (managed in account settings under Notes).
The note section includes:
- A template selector dropdown — choosing a template auto-populates the body with the template's content
- An editable body field — the user can modify the pre-populated text before sending
- Email & sharing controls — toggle visibility and email delivery for client and server
Note templates support variable substitution:
{{contractor_name}}— replaced with the process server company name or individual name{{user_name}}— replaced with the current user's name{{feedback_content}}— replaced with any feedback content from the diligence review
The template's default sharing settings (visibility and email notifications) are pre-filled but can be overridden by the user for each workflow submission.
When enabled, the user can create a task associated with the job directly from the workflow. The full task creation form (label, body, status, assignee, category, due date) is embedded in the workflow view.
When enabled, an "Attempt Feedback (Optional)" section appears in the workflow form. This is designed for quality review workflows where you need to provide specific feedback on individual attempts.
Each feedback entry includes:
- Attempt — a dropdown to select which attempt the feedback is for (shows serve type and date)
- Reject Reason — a predefined reason:
- Insufficient attempt details
- Incorrect time of day
- Wrong service method
- Missing documentation
- Did not follow instructions
- Other
- Comment — free-text details
Users can add multiple feedback entries (one per attempt) and remove entries they don't need. Feedback data is saved with the workflow submission.
Workflows have configurable action buttons that the user clicks to submit their review:
| Setting | Description |
|---|---|
| Primary Action | The main positive button (defaults to "Approve"). Typically used for approving, completing, or passing a job. |
| Secondary Action | The alternative button (defaults to "Reject"). Typically used for rejecting, failing, or flagging a job. |
| Skip Action | When enabled, a "Skip" button appears allowing the user to move to the next job without taking action. Skipped jobs won't reappear until the workflow session is reset. |
The button labels are fully customizable. For example, you might use "Complete" / "Incomplete", "Pass" / "Fail", or "Approve" / "Reject" depending on the workflow's purpose.
Completion settings control when jobs are considered "done" in the workflow and removed from the queue.
- Primary action is clicked — Jobs are marked complete when the user clicks the primary button (e.g., "Approve"). Completed jobs no longer appear in the queue.
- Secondary action is clicked — Jobs are marked complete when the user clicks the secondary button (e.g., "Reject"). Completed jobs no longer appear in the queue.
You can enable one or both:
- Both enabled — Jobs leave the queue after any action (useful for one-pass reviews)
- Only primary enabled (default) — Rejected jobs stay in the queue for re-review; approved jobs are removed
- Only secondary enabled — Approved jobs stay in the queue; rejected jobs are removed
- Neither enabled — Jobs never auto-complete and always remain in the queue
These filters control which jobs appear in the workflow queue in the first place:
| Criteria | Description |
|---|---|
| Require terminal attempt | Only jobs with a terminal attempt (a "served" status like Personal Service, Substituted Service, etc.) appear in the queue. Jobs still in progress are excluded. |
| Exclude jobs already reviewed | Jobs that already have a diligence review audit record are excluded. This prevents the same job from being reviewed twice. |
Workflows can appear as their own queue charts on the fulfillment specialist dashboard, similar to the built-in queues (Pending Dispatch, Pending Acceptance, etc.).
Setup:
- Create and activate a workflow
- Go to the user management page and edit a user
- Under Dashboard Workflow Queues, check the workflows that should appear on that user's dashboard
Only explicitly selected workflows appear on a user's dashboard. If no workflows are selected, no workflow queue charts are shown. This is configured per-user, so different team members can see different workflow queues.
When displayed on the dashboard, the workflow appears as a stacked bar chart. Clicking a chart segment navigates to the workflow's show page to begin working through the queue.
Dashboard queue linking connects the built-in fulfillment dashboard charts (Pending Dispatch, Pending Acceptance, etc.) to workflows. This provides a seamless path from the dashboard into a workflow.
How it works:
-
On the workflow edit page, each assignment rule has a Dashboard Queue Link dropdown.
-
The dropdown lists all built-in dashboard queues and their sub-groups:
Queue Sub-groups Pending Dispatch Standard, Rush Pending Acceptance Standard, Rush, Declined Out for Service Standard, Rush, Past Due Rejected (Needs Review) Rejected by Court, Partially Rejected by Court Pending Affidavit Pending Creation, Pending Signature Pending Closeout Pending Closeout -
You can link at the queue level (e.g., "Pending Dispatch" — matches all segments in that queue) or at the group level (e.g., "Pending Creation" under Pending Affidavit — matches only that specific group).
-
When a user clicks a chart segment on the dashboard, the system checks if any workflow rule is linked to that queue/group AND if the workflow's job types overlap with the clicked segment's job types. If a match is found, the job index page shows an "Enter Workflow" banner with a button that links directly into the workflow.
Granularity by job type: Different rules (even across different workflows) can target the same queue for different job types. For example:
- Workflow A, Rule 1: links "Pending Dispatch" with job types = [SOP]
- Workflow B, Rule 1: links "Pending Dispatch" with job types = [pFiling]
- Dashboard → clicking SOP segment in Pending Dispatch → shows "Enter Workflow" for Workflow A
- Dashboard → clicking pFiling segment → shows "Enter Workflow" for Workflow B
- Dashboard → clicking a segment with no matching workflow → no banner, normal job list behavior
When a user enters a workflow (from the dashboard, the workflow index, or a dashboard queue link), the experience is:
The workflow presents a split-screen layout:
- Left side (60%) — The workflow form: guidelines, custom fields, action sections, and submit buttons
- Right side (40%) — The job sidebar: selected job elements showing the job's information
-
One job at a time — The workflow presents a single job, starting with the oldest (ordered by the earliest terminal attempt date, then by creation date for jobs without terminal attempts).
-
Progress tracking — A progress bar and counter (e.g., "3 / 12") at the top shows how many jobs have been completed out of the initial queue size.
-
Guidelines — If configured, a collapsible "Guidelines" section shows the attempt requirements with checkmarks indicating which are met by the current job.
-
Review and act — The user reviews the job information in the sidebar, fills out any required form fields, and takes one of three actions:
- Primary action (e.g., "Approve") — Creates a workflow submission with "approved" status, saves any job edits, creates notes/tasks if configured, and advances to the next job.
- Secondary action (e.g., "Reject") — Same as primary but with "rejected" status.
- Skip — Moves to the next job without creating a submission. The skipped job won't reappear in the current session.
-
Completion — When no more jobs remain in the queue, the user is redirected to the dashboard with a message.
You can also trigger a workflow review for a specific job by navigating to:
/workflows/:workflow_id?job_id=:job_id
This shows the workflow form for that single job. After completing the review, the user is redirected back to the job page (with an "Exit" button instead of "Skip"). This is useful for reviewing a specific job outside of the normal queue flow.
The workflow tracks progress in the user's browser session:
- Skipped jobs — Jobs the user skipped won't reappear during the current session
- Initial count — The queue size when the session started (used for progress bar)
- Rule index — Which assignment rule is being used to filter the queue
- In-progress flag — Whether the user has started working through the workflow
Starting a workflow with ?fresh=true in the URL clears the session and starts over with a fresh count.
Jobs are automatically assigned to workflows based on assignment rules. The system evaluates rules at two points:
When a new job is created, the system:
- Finds all active workflows matching the job's type
- For each workflow, evaluates rules with "On job creation" enabled
- Checks if the job matches all criteria in the rule
- If matched, increments a Redis counter for that rule
- If the counter aligns with the assignment rate, the job is assigned
When a job's criteria-relevant fields change (status, service type, etc.), the system repeats the same process for rules with "On job update" enabled.
When an attempt is created, updated, or destroyed, the system re-evaluates workflow assignment if the SOP's service status changed or the attempt's serve type changed. This ensures that Service Status and Service Type criteria are evaluated when the underlying data changes, even though the job itself may not have been saved.
When mailing details are updated in bulk (via the Bulk Mailing feature), the system re-evaluates workflow assignment for all affected jobs. This ensures that Mailing Status criteria are evaluated even though update_all bypasses normal model callbacks.
When a job is completed in a workflow (via the primary or secondary action, if the workflow's completion settings mark that action as completing), the system re-evaluates the job for assignment to other workflows. This re-evaluation bypasses the normal timing check (create/update) so that all rules are considered regardless of their timing settings.
This is primarily relevant for the Exclusivity criterion. For example:
- Workflow A has Exclusivity enabled ("Only assign if the job is not in another active workflow")
- Workflow B has no such restriction
- A new job matches both workflows — it gets assigned to B, but A skips it because it's already in B
- A user completes the job in B (e.g., clicks "Approve")
- The system re-evaluates the job — since it's no longer in an active workflow (B is completed), it now gets assigned to A
The assignment rate controls what percentage of matching jobs actually enter the workflow:
| Rate | Effect |
|---|---|
| Every job (100%) | All matching jobs are assigned |
| Every 2nd job (50%) | Every other matching job |
| Every 3rd job (33%) | Roughly one in three |
| Every 4th job (25%) | Roughly one in four |
| Every 5th job (20%) | Roughly one in five |
| Every 10th job (10%) | Roughly one in ten |
The rate uses a persistent Redis counter per rule. When the counter (incremented for each criteria match) is evenly divisible by the rate, the job is assigned. This provides a roughly even sampling of jobs over time.
When a job is assigned to a workflow:
- The workflow's ID is added to the job's
assigned_workflow_idsarray - The job will now appear in the workflow's queue for users to process
- Only the first matching rule per workflow is used (if Rule 1 matches, Rules 2+ are skipped for that workflow)
Each time a user completes a workflow action (approve or reject), a Workflow Submission record is created containing:
- Which workflow and user performed the action
- Which job was reviewed
- The action taken (approved / rejected)
- Custom field responses (if any custom fields were configured)
- Attempt feedback entries (if attempt feedback was enabled)
- The contractor note text (if a note template was used)
- A reference to the DiligenceReviewAudit record created for the review