Prior Authorization Desk: Deadlines That Follow Each Payer's Current Rules

Thirty open cases, three payers and rules that change mid-quarter

A prior authorization desk turns each request into one of a few outcomes: submit to the payer, expedite, hold for missing documents, or reject because the service is not covered. The outcome sets a deadline, and the deadline depends on the payer, because each payer's rules are its own and they get corrected mid-quarter.

Cases live in Salesforce, each payer's coverage rules live on a Notion page, the supporting documents are filed in Box, and the records team confirms what it has collected in a weekly email. Specialists work from all four, plus a queue report that is regenerated from Salesforce and drifts out of date between runs. When a payer corrects a rule, someone has to find every case it touches and redo the deadlines by hand.

Who works in the room

In the desk's room, a message that names no agent goes to Ada, which owns triage, dispositions and deadlines. Ryan owns the queue report and the escalation sweep, and Fin owns anything that answers an email thread. The room guidelines say cases are referred to by case number only and that each update gets one reply on the thread that asked, so Fin drafts exactly one answer there and nowhere else. When Ada finishes a re-run, it hands the batch to Ryan in the thread to re-read from Salesforce before the lead confirms it.

From triage to quarter close

The policy lives in Drive and each payer's rules on its Notion page. Every stage below ends with a person approving what changes in Salesforce.

When a payer, a reviewer or the records team changes the picture

Updates arrive in the middle of everything. The records team's weekly email confirms documents for six held cases, and the policy counts that confirmation as meeting the documentation rule even before the file shows up in Box. A payer corrects a rule on its Notion page, which moves three deadlines. Peer reviews come back approving two cases and denying one. Ada re-runs only the cases each update names and writes a short reason on every case that changes.

The labels matter as much as the outcomes. A case denied after peer review is recorded as a peer review denial, not as a service that is not covered, because the next step for each is different. Fin drafts one reply on the thread that asked, with the case number and the new deadline, and a specialist sends it. Ryan then re-reads the remaining reject and held batch from Salesforce, so the count in the thread matches the records. An automation flags any case whose deadline passes without a submission.

What the checks catch

• A held case the records team has confirmed in writing, which the policy treats as documented before Box shows the file
• A queue report that lists a held case, misses a submit case or shows a deadline from before the payer's correction
• A peer review denial recorded as not covered, which would send the case down the wrong path
• An escalation sweep that resets priorities on cases the memo does not name
• A second reply on a thread that already has its answer, or a reply posted on the wrong case

What stays with people

• Approving every disposition, deadline and priority change before Salesforce is updated
• Sending each reply to a payer, a clinic or the records team, which Fin prepares as a Gmail draft
• Reading a payer's rule correction where the wording leaves room for doubt
• Signing the quarter close and its per-case closing activities

Integrations in this workflow

Kylon is not a prior authorization system and it does not replace one. It sits across the desk's existing tools and holds the coordination between them. Ada reads Salesforce, Notion and Box through a lasting grant the desk lead approved for this room, and Fin drafts in Gmail as the specialist it is working for, with access checked on every call.

• Box
• Gmail
• Google Drive
• Notion
• Salesforce
• Slack

• Salesforce holds one case per request, with disposition, deadline, priority and each closing activity
• Notion holds each payer's coverage rule page
• Box holds the supporting documents filed for each case
• Gmail carries the records team's confirmations and the replies on case threads
• Google Drive keeps the authorization policy, the escalation memo and the draft queue report
• Slack is where specialists outside the room flag payer calls and peer review times

Where to start

Begin with one quarter and one payer. Connect the Salesforce object that holds your cases, share that payer's Notion rule page with the room, and write the one rule in the room guidelines: an agent proposes dispositions and deadlines, and the desk lead approves every change before a case is updated.

“Every deadline in the queue traces back to a rule page and a person who approved it.”

Set it up with your agent

Open a new Room, add your agent and paste this prompt. It connects the tools, builds the App with you and asks for your rules one step at a time, and nothing goes out until a person approves it.