Overview
When a payer that requires an auth becomes active on a resident's coverage, the system automatically creates an Auth workflow to track the process from start to finish.
How an Auth Gets Created
There are two paths for creating an Auth workflow:
Automatic (system-driven):
When a payer flagged as "Auth Required" becomes active on a resident's payer tree, the system automatically creates an Auth in "Needed" status.
This happens both in real-time (at the moment the payer is saved/activated) and via a daily background job that catches anything missed (e.g., future-dated payers whose start date has arrived).
The auto-create is gated by two company-level settings:
The Auth workflow must be enabled for the company.
The Auto-create toggle for the Auth workflow must be on.
Manual (user-driven):
A user can create an Auth directly from the resident's case Auths tab.
Auth Statuses (Lifecycle)
An auth progresses through statuses based on what data has been entered:
Status | What It Means | How It's Determined |
Needed | Auth required but no action taken yet | Initial status on auto-create |
Submitted | Auth has been requested from the payer | "Auth Requested" date is filled in |
Received | Auth is approved and in effect | "Auth Begin Date" is filled in |
Update Needed | The "Next Update Due" date has passed | System flips this automatically via daily job |
Expired | Auth end date has passed | System flips this automatically via daily job |
Inactive | Auth was ended due to external change | Set by system |
Automatic Status Transitions (Behind the scenes)
Two daily jobs manage auth status:
Expiration job: Any auth in Submitted, Received, or Update Needed status whose Auth End Date has passed → flipped to Expired.
Update Needed job: Any auth in Received status whose "Next Update Due" date has arrived → flipped to Update Needed.
Automatic Inactivation
The system sets an auth to Inactive (with a recorded reason) in two scenarios:
Payer change: If the payer that triggered the auth is removed or replaced on the resident's coverage, the auth is marked Inactive with reason "Payer change."
Discharge: If the resident is discharged, all their live (current) auths are marked Inactive with reason "Discharge."
Inactive auths preserve their original Auth End Date and are **not** processed by the expiration jobs.
Resuming an Inactive Auth
If an auth was inactivated (e.g., a payer was removed by mistake), a user can Resume it. Resuming clears the inactive reason and recomputes the status from the existing data — if the auth had been worked (dates filled in), it returns to its data-derived status; if untouched, it goes back to "Needed."
Re-creation After End
If a resident still has an active auth-required payer but their auth expires or becomes inactive, the system will auto-create a new Auth (back to "Needed") the next time the daily job runs — ensuring there's always a live auth tracking the requirement while the payer is active.