Runbook: Modifying Review Requirements

Last updated: March 5, 2026 · Applies to: Howard County Permitting

Before You Start

This runbook covers changes to existing permit type workflows. If you need to create a brand new permit type, see the Adding a New Permit Type runbook instead.

Common reasons to modify review requirements:

A department is added to or removed from the review process
A permit type needs an extra review step (e.g., adding Plan Review)
SLA deadlines or default reviewers need to change
A review step is being consolidated or split

What you need:

GovAssist admin access (Automation Builder + Entity Manager)
The name of the permit type being modified
The specific change requested (which review step, which department)

Always test changes on a test record before relying on them in production. See the Testing Automations Safely runbook for the recommended approach.

Understand Your Workflow Type First

The modification steps differ depending on whether the permit uses a sequential or FORK/JOIN workflow. Before making any changes, identify which type applies.

Workflow Type	Permit Archetypes	How It Works
Sequential	A1, A2, A2+, E1	Steps happen one after another. Each step's completion triggers the next.
FORK/JOIN	B1, B2	Multiple reviews happen in parallel. A FORK creates several Review Tasks at once; a JOIN waits for all of them to finish.

Not sure which type your permit uses? Open the Automation Builder, find the permit type's folder, and look at the automation names:

Names containing FORK and JOIN → it's B1/B2
Automations numbered sequentially (1, 2, 3…) → it's A1/A2/A2+

Use the table below to jump to the right section:

Scenario	Section
Add a review step to a sequential workflow	Section 1
Remove a review step from a sequential workflow	Section 2
Add a department to a FORK/JOIN workflow	Section 3
Remove a department from a FORK/JOIN workflow	Section 4
Change reviewer assignments	Section 5
Change SLA or due dates	Section 6

Section 1: Adding a Review Step to a Sequential Workflow

Scenario: A permit type follows steps A → B → C, and you need to insert a new step X between B and C — making it A → B → X → C.

Example: Residential HVAC currently goes: Acceptance → Issuance → Final → CofC → Close. The department wants to add a "Plan Review" step after Acceptance, making it: Acceptance → Plan Review → Issuance → Final → CofC → Close.

Create the status field (if needed)

If the new review step doesn't already have a status field on the parent entity:

Go to Entity Manager → select the parent entity (e.g., Trade Permit)
Open the Fields tab
Click Add Field and configure:
- Label: "[New Step] Review Status" (e.g., "Plan Review Status")
- Type: Dropdown
- Options: Copy from an existing review status field — all share the same 29 options
Click Save and note the field name and ID for use in automations

Create the new automation

The new automation sits between the existing steps. It triggers when the upstream step completes, guards against duplicates, creates the Review Task, and marks the new status field as Pending.

Build it using the standard self-deactivating pattern:

Component	Value
Name	"[Permit Type] - [Upstream Step] → Create [New Step]"
Trigger	When Record Matches Condition
Condition 1	Routing (e.g., Trade Type = HVAC AND Category = Residential)
Condition 2	Upstream status = completion value (e.g., Acceptance Status = Approved)
Condition 3	New status field is empty (dedup guard)
Action 1	Create Record → Review Task with the appropriate Review Type
Action 2	Update Record → Set new status field = Pending, update Application Status

Save and Publish the automation.

Modify the downstream automation

The automation that previously triggered on the upstream step's completion must now trigger on the new step's completion instead.

Old trigger: "Acceptance Status = Approved" → triggers "Create Issuance"
New trigger: "Plan Review Status = Approved" → triggers "Create Issuance"

Open the existing downstream automation (e.g., "Create Issuance")
Edit the Trigger conditions: change the step-completion condition from the old upstream field to the new step's field
Keep all other conditions unchanged (routing, dedup guard)
Save and Publish

Update Application Status mapping

If the new step changes the overall workflow progression, update the Application Status values in the Update Record actions across the affected automations.

Step	Application Status (before)	Application Status (after)
Acceptance complete	Approved	Approved
Plan Review complete	(didn't exist)	Ready for Issuance (new)
Issuance complete	Issued	Issued

Verify the chain

Walk through each automation's trigger and confirm that the previous step's output matches the next step's trigger condition. Then:

Create a test record and verify the full chain fires end-to-end
Edit the test record at each step — no duplicate Review Tasks should appear
Confirm Application Status advances correctly at each stage

Visual summary of the chain change:

Before: [Acceptance] ──────► [Issuance]

After: [Acceptance] ──► [Plan Review] ──► [Issuance]

The downstream automation's trigger must be updated so it waits for Plan Review — not Acceptance — before creating the Issuance task.

Section 2: Removing a Review Step from a Sequential Workflow

Scenario: A permit type follows steps A → B → X → C, and step X is no longer required — making it A → B → C.

Example: A Fire Permit goes Acceptance → Plan Review → Issuance → Final → CofC → Close. Plan Review is no longer needed. The new chain: Acceptance → Issuance → Final → CofC → Close.

Modify the downstream automation

The automation that previously triggered on step X's completion must now trigger on step B's completion instead.

Open the automation that was triggered by the removed step (e.g., "Create Issuance")
Edit the Trigger conditions: change the trigger from the removed step's field to the upstream step's field
- Old: "Plan Review Status = Approved"
- New: "Acceptance Status = Approved"
Keep all other conditions unchanged
Save and Publish

Deactivate the removed automation

Open the automation for the removed step (e.g., "Accepted → Create Plan Review")
Deactivate it (toggle off)
Do not delete it — keep it deactivated in case you need to restore it later

Deactivated automations serve as documentation of the previous workflow. If the department changes direction, you can reactivate rather than rebuild from scratch.

Handle the orphaned status field

The status field for the removed step (e.g., "Plan Review Status") remains on the entity but will no longer be set by any automation.

Option	When to Use
Leave it	Safest. The field is unused but existing records retain their values.
Hide it	If the field clutters the form, hide it in the form layout (Entity Manager → Form → drag to hidden section). The field still exists but users don't see it.

Do not delete the field unless you are certain no existing records use it and no other automations reference it.

Update Application Status mapping

Remove the Application Status value for the removed step from the remaining automations so the progression is smooth.

Step	Application Status (before)	Application Status (after)
Acceptance complete	Approved	Approved
~~Plan Review complete~~	~~Ready for Issuance~~	(removed)
Issuance complete	Issued	Issued

Handle in-flight records

Records currently waiting at the removed step need manual attention — their workflow will stall because no automation advances them past it.

Identify affected records: Search for records where the removed status field = "Pending" or "Review in Process"
Advance them manually: Set the downstream trigger field to the appropriate value (e.g., set Acceptance Status = Approved) to trigger the next automation
Or close them: If the review is truly no longer needed, mark them as "Review Not Required" and let the downstream automation pick them up

Section 3: Adding a Department to a FORK/JOIN Workflow

Scenario: A Building Permit type currently forks into reviews by Zoning, Building, and Electrical. A new department (e.g., DPW) must now review it too.

Create the review status field (if needed)

If there is no existing review status field for the new department on the parent entity:

Go to Entity Manager → select the parent entity (e.g., Building Permit)
Add Field → "DPW Review Status" (dropdown, copy options from any existing review status field)
Save and note the field name and ID

Modify the FORK automation

Open the FORK automation (e.g., "Res Bldg - FORK - New SFD")
Add a new Create Record action node:
- Entity: 7 Master Review Tasks
- Review Type: [new department's review type, e.g., "DPW Review"]
- Review Status: Pending
- Parent association: same as other Create Record nodes
- Name: "[Department] - [Record Number]" (use dynamic binding)
- Reviewer: [default reviewer for the department]
Modify the existing Update Record action to also set the new department's status field:
- Add: "DPW Review Status = Pending"
- Keep all existing field updates
Save and Publish

The Update Record action in a FORK must set ALL review status fields to Pending — including the new one. This is how the dedup guard works for FORKs. Omitting the new field will cause duplicate Review Task creation on record edits.

Modify the JOIN automation

Open the matching JOIN automation (e.g., "Res Bldg - JOIN → Create Issuance")
Add a new trigger condition for the new department:
- "DPW Review Status IN [Approved, Approved with Conditions, Review Not Required]"
Keep all existing conditions — the JOIN fires only when all departments are done
Save and Publish

Verify

Create a test record → verify the new number of Review Tasks appears (e.g., 4 instead of 3)
Complete all reviews including the new department → verify JOIN fires
Complete only the original reviews (leave new department pending) → verify JOIN does NOT fire
Set the new department to "Review Not Required" → verify JOIN fires with other departments approved

Before and after:

Before: FORK creates 3 RTs (Zoning, Building, Electrical). JOIN checks 3 fields.

After: FORK creates 4 RTs (+ DPW). JOIN checks 4 fields. The JOIN will not fire until DPW review is complete (or marked Not Required).

Section 4: Removing a Department from a FORK/JOIN Workflow

Scenario: A Building Permit type currently forks into 6 reviews, but Health Department review is no longer required for this variant.

Modify the FORK automation

Open the FORK automation
Remove the Create Record action for the department being removed (e.g., Health Dept)
Modify the Update Record action: remove the line that sets the removed department's status field
- Remove: "Health Dept Review Status = Pending"
- Keep all other field updates
Save and Publish

Modify the JOIN automation

Open the matching JOIN automation
Remove the trigger condition for the removed department's status field
- Remove: "Health Dept Review Status IN [Approved, Approved with Conditions, Review Not Required]"
Keep all remaining conditions
Save and Publish

If you remove a department from the FORK but forget to update the JOIN, the JOIN will never fire — it will keep waiting for a review that no longer gets created.

Handle in-flight records

Records currently in the FORK stage may already have a Review Task for the removed department:

RT Status	Action
Pending	Set it to "Review Not Required" so the JOIN condition is satisfied
In Process	Decide whether to let the review finish or cancel it
Already complete	No action needed — the JOIN condition is already satisfied

Verify

Create a test record → verify the correct (reduced) number of Review Tasks appears
Complete all remaining reviews → verify JOIN fires
Confirm the removed department's RT does not appear on new records

Section 5: Changing Reviewer Assignments

To change the default reviewer on a single automation:

Open the automation in the Automation Builder
Find the Create Record action
Change the Reviewer field value to the new user
Save and Publish

To update multiple automations (e.g., a staff member has left):

Search for the person's name in the Automation Builder, or check the affected permit type's folder for automations that reference them
Open each automation, update the Reviewer field, save, and publish
Create a test record to confirm the new reviewer appears on created Review Tasks

Changing the reviewer on an automation only affects future Review Tasks. Existing Review Tasks already assigned to the old reviewer will not change. To reassign existing tasks, update them directly in the Review Task records.

Section 6: Changing SLA / Due Dates

Open the automation that creates the Review Task for the step
Find the Create Record action
Change the Days Allowed field value to the new number
If the automation calculates Due Date based on Days Allowed, update the date formula:
- Due Date = Created Date + [new Days Allowed] days
Save and Publish

Like reviewer changes, SLA changes only affect future Review Tasks. Existing tasks keep their original due dates.

Quick Reference

Scenario	Automations to Touch	Field Changes	JOIN Update Needed?
Add step to sequential	Create 1 new + modify 1 downstream	New status field may be needed	No
Remove step from sequential	Modify 1 downstream + deactivate 1	Status field can be hidden	No
Add dept to FORK	Modify FORK (add Create Record + update Update Record)	New review status field may be needed	Yes — add condition
Remove dept from FORK	Modify FORK (remove Create Record + update Update Record)	No field changes	Yes — remove condition
Change reviewer	Modify Create Record action(s)	None	No
Change SLA / due date	Modify Create Record action(s)	None	No

Troubleshooting

Symptom	Likely Cause	Fix
New step creates RT but next step never fires	Downstream automation still triggers on old field	Update the downstream automation's trigger to reference the new step's status field
JOIN never fires after removing a department	JOIN still checks the removed department's status	Remove that condition from the JOIN trigger
JOIN fires before new department reviews	JOIN doesn't check the new department's status	Add the new department's status field condition to the JOIN trigger
Duplicate RTs after modifying a FORK	Update Record action doesn't set the new department's status	Ensure the FORK's Update Record sets all review status fields (including new ones) to Pending
Old records stuck at removed step	In-flight records have no automation to advance them	Manually set the downstream trigger field value on affected records
Changed reviewer not appearing on new tasks	Automation not republished after edit	Publish the automation after saving

Modification Checklist

Use before and after every change.

Before Modifying

Identified the permit type and its current workflow archetype (sequential or FORK/JOIN)
Listed all automations in the permit type's folder
Determined which automations need changes
Verified whether a new status field is needed

Sequential Workflow Changes

New automation created (if adding a step)
Downstream automation trigger updated to reference the correct field
Removed automation deactivated — not deleted (if removing a step)
Application Status mapping updated across affected automations
Chain verified: each step's output matches the next step's trigger input

FORK/JOIN Workflow Changes

FORK automation updated (Create Record added or removed)
FORK's Update Record sets all current review status fields
JOIN trigger conditions updated to match the current FORK
JOIN checks exactly the departments that the FORK creates Review Tasks for

After Modifying

All changed automations saved and published
End-to-end test passed on a new test record
Dedup test passed — no duplicate Review Tasks on record edit
In-flight records identified and handled (if removing a step)
Folder organization updated if automation names changed

This runbook covers modifications to the 150+ automations configured as of February 27, 2026.