--- title: "Prior Authorization Desk Workflow With AI Agents | Kylon" description: "How a prior authorization desk triages cases against payer rules, reviews the queue report and absorbs payer corrections in one Kylon room, with each change approved." url: "https://kylon.io/use-cases/prior-authorization-desk" language: "en" --- [HOME](https://kylon.io/)\>[Use Cases](https://kylon.io/use-cases)\>Prior Authorization Desk: Deadlines That Follow Each Payer's Current Rules Use Case9 min read # Prior Authorization Desk: Deadlines That Follow Each Payer's Current Rules Each prior authorization case gets a disposition and a deadline from its payer's current rule page, and keeps the right one through documentation batches, payer corrections and peer reviews. The desk lead approves every change before Salesforce is updated. [Get started](https://app.kylon.io/sign-up) Kylon TeamProduct November 6, 2026 ## 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 People - Prior authorization lead Approves every disposition, deadline and priority change and signs the quarter close - Authorization specialists Work cases with payers, schedule peer reviews and send the replies on case threads - Records team Collects the supporting documents and confirms what it has filed in a weekly email Agents - AdaCase triage Applies the policy and each payer's rule page to every open case, checks which required documents are on file and proposes a disposition and deadline Salesforce[Notion](https://kylon.io/integrations/notion)BoxGoogle Drive - RyanQueue report and escalations Checks the queue report against current dispositions, runs the escalation sweep and re-reads each batch from Salesforce before it is confirmed SalesforceGoogle Drive - FinCase thread replies Reads the records team's confirmations and drafts the single reply each case thread needs, for a specialist to send [Gmail](https://kylon.io/integrations/gmail) [Slack](https://kylon.io/integrations/slack) 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. ```mermaid flowchart TD triage["Ada proposes a disposition and
deadline from each payer's rules"] approve["Desk lead approves before
any case field changes"] queue["Ryan checks the queue report
against current dispositions"] records["Records team confirms
its filings by email"] payer([A payer corrects a rule
on its Notion page]) held["Ada updates only the held
cases whose outcome changes"] rerun["Ada re-runs the rejected
and held cases it touches"] reply["Fin drafts one reply on
the thread that asked"] changes["Desk lead approves the changes,
a specialist sends the reply"] sweep["Ryan marks the cases that meet the
escalation memo as urgent"] peer([Peer reviews come back]) denial["Ada records a denial as a peer
review denial, not as not covered"] close["Ada logs one closing activity per
case, checked by Ryan"] sign["Desk lead approves the outcomes
and signs the quarter"] triage --> approve --> queue queue --> records & payer records --> held payer --> rerun --> reply held & reply --> changes changes --> sweep & peer peer --> denial sweep & denial --> close --> sign class triage,queue,held,rerun,reply,sweep,denial,close agent class approve,records,changes,sign person class payer,peer event classDef agent fill:#FFFFFF,stroke:#DCD3C8,color:#1B1712 classDef person fill:#EEF0E3,stroke:#6E7447,color:#1B1712 classDef event fill:#F4ECDD,stroke:#F4ECDD,color:#564C42 ``` | Stage | What happens | Who acts | Who decides | | --- | --- | --- | --- | | Triage | Every open case gets a disposition and a deadline from the policy and its payer's rule page | Ada, from Salesforce, Notion and Box | The desk lead approves before any case field changes | | Queue report review | The report should hold exactly the submit and expedite cases, once each, with the right deadline | Ryan | The desk lead approves the correction count, posted once as a Salesforce note | | Documentation batch | The records team's confirmation is checked against every held case, and only cases whose outcome changes are updated | Ada, with Fin reading the email | The desk lead approves the changed cases | | Payer correction and appeals | A corrected rule re-runs the rejected and held cases it touches, and an appeal outcome gets one reply on its own thread | Ada, then Fin for the reply | The desk lead approves the changes and a specialist sends the reply | | Escalation sweep | Cases that meet the escalation memo are marked urgent, and every other priority is left as it is | Ryan | The desk lead approves the list | | Peer review and close | Peer review outcomes are recorded, then one closing activity per case is logged in Salesforce | Ada, checked by Ryan | The desk lead approves the outcomes and signs the quarter | Stages of a quarterly authorization cycle. Case numbers, payers and counts in this example are illustrative. ## 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](https://kylon.io/integrations/gmail) - Google Drive - [Notion](https://kylon.io/integrations/notion) - Salesforce - [Slack](https://kylon.io/integrations/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. Set-up prompt Set up our prior authorization desk in this Room. Take it one step at a time and wait for my OK before you move on. 1. Connect Box, Gmail, Google Drive, Notion, Salesforce and Slack. Tell me which ones still need connecting. 2. Ask me who works this desk: the prior authorization lead, the authorization specialists who work cases and send replies, and the records team who confirms documents. Help me invite them to this Room. 3. Build an Authorization Queue App with columns Triage, Held for documents, Submitted and Decided, one record per case. Pull the open cases from Salesforce. 4. For each case, read our policy in Google Drive and that payer's rule page in Notion, check which supporting documents are on file in Box, and propose a disposition and a deadline. Show me cases where something does not line up, including held cases the records team has confirmed in writing, queue report mismatches, and peer review denials recorded under the wrong label. 5. Draft one reply per case thread in Gmail for a specialist to send. Hold every draft until the prior authorization lead approves the disposition, deadline, priority change or correction, and approves each changed case before any field in Salesforce is touched. 6. Write into this Room's guideline that agents propose and the prior authorization lead approves every change before Salesforce is updated, and that each case thread gets exactly one reply on the thread that asked. 7. After one clean quarter, offer to turn the deadline escalation sweep into an Automation. Before you start, ask me for our rules one at a time. [Get started](https://app.kylon.io/sign-up) Your first company harness. Where humans and agents run your business together. [Get started](https://app.kylon.io/sign-up) ## More Use Cases [View all](https://kylon.io/use-cases) [ ### Clinical Site Monitoring: A Monthly Visit Plan That Holds Up When Things Change Site dispositions, monitor assignments, schedule reviews and mid-cycle changes run through one Kylon room. Agents work the Salesforce and Box records, and the desk lead approves every assignment before a visit is booked. Healthcare & life sciencesScheduling & dispatchCompliance & risk ](https://kylon.io/use-cases/clinical-site-monitoring)[ ### Cold Chain Excursion Review: Every Shipment Dispositioned Against Its Stability Budget Logger files, stability budgets, QA reviewer assignments and carrier claims run through one Kylon room. Agents total the minutes out of range and check the manifest, and the QA lead approves every release and reject before a record changes. Healthcare & life sciencesCompliance & risk ](https://kylon.io/use-cases/cold-chain-excursions)