Skip to main content
    SupportContact
    Service workflows

    Assigning cases to the first available agent in Salesforce.

    Cases arrive faster than agents accept them. Round-robin gives the next case to whoever is up, even if they are not online. Availability is the routing signal that most teams ignore. Ortoo Orchestrator handles assignment to the first available agent as part of one workflow.

    TEAMS RUNNING ON ORTOO ORCHESTRATOR

    IG
    Jaguar Land Rover
    Komatsu
    OppFi
    Sage
    Splunk
    Verivox
    Volvo
    IG
    Jaguar Land Rover
    Komatsu
    OppFi
    Sage
    Splunk
    Verivox
    Volvo

    What it is

    First available agent routing, in plain terms.

    First available agent routing means assigning each inbound case to the next agent who is online, has capacity, and has the right skills, in that order. The workflow respects all three signals together rather than treating availability as the only criterion.

    First-available routing sits inside Ortoo Orchestrator. The routing capability inside Ortoo Orchestrator reads live agent status, capacity remaining, and skill match, and assigns the case in one step.

    The problem

    First available agent routing breaks when availability is the only criterion

    Native Salesforce assignment does not factor in skills, capacity, and territory together as one decision. First available agent routing sounds simple until you try to make it work at volume. Native round-robin gives the next case to whoever is up in the rotation, regardless of whether they are online, at capacity, or have the skills. Agents who stepped away get cases assigned to them; the cases sit until the agent returns.

    The result is queues that look balanced on paper but actually concentrate work on agents who are present and have capacity to absorb it. Customers wait while their case sits on an agent who never picks it up. SLA reporting shows the cost after the fact.

    First available is not the same as next in rotation.

    Ortoo Orchestrator combines availability, capacity, and skills in one routing decision. Cases route to agents who are actually online with capacity to take the work, not just to whoever is next in line.

    // HOW IT WORKS

    Triggered by case context. Not by who is watching the queue.

    1. 01

      // STEP 01

      Live agent status feeds the routing decision.

      Agent presence, capacity remaining, and skill profile are all read in real time. The workflow does not route to agents who are offline or at workload limit.

      1. Agent presence

        Live signal

      2. Capacity left

        Per agent

      3. Skill profile

        Configured

      Step 01 — Status
      01
    2. 02

      // STEP 02

      The case routes to the best-fit available agent.

      Inside the available pool, the workflow picks the agent based on skill match and current load. If no agent meets all criteria, the workflow falls back to the next-best match per the team's rules.

      1. Available pool

        Online + has capacity

      2. Skill filter

        Best match

      3. Fallback rule

        Relax one criterion

      Step 02 — Match
      02
    3. 03

      // STEP 03

      Capacity refreshes as cases close.

      Workload limits per agent refresh in real time as cases are accepted, transferred, or resolved. The next routing decision reflects current state, not yesterday's snapshot.

      1. Push case

        To matched agent

      2. Decrement capacity

        Live update

      3. Log decision

        Inputs + outcome

      Step 03 — Assign
      03

    What good availability-based routing needs

    Three things separate working first-available routing from round-robin.

    Most teams default to round-robin and call it availability-based. Three things make the routing actually respect who can do the work right now. The path is operationally realistic: start with one workflow at a time, expand step by step as the team is ready.

    Book a demo

    Live agent presence

    Routing respects who is actually online, not who is next in rotation.

    Capacity awareness

    Workload limits enforced on every assignment. Available is not the same as overloaded.

    Skills as the filter

    Inside the available pool, skills match the case to the right agent.

    Before vs after

    What changes when first-available routing runs as a workflow.

    The cases do not change. What changes is whether they land on agents who can actually take them.

    Before

    Before

    1. 01Round-robin
    2. 02Offline assignments
    3. 03Static capacity
    4. 04Queue waits

    Cases route to whoever is next, regardless of whether they can pick them up.

    After

    With Ortoo Orchestrator

    1. 01Live presence
    2. 02Online only
    3. 03Real-time capacity
    4. 04First-available

    Cases route to the first available agent with capacity and skills to handle them.

    Where it fits

    Works with the Salesforce tools you already use.

    First available agent routing for high-volume service desks

    High volumeService operations

    Teams handling thousands of inbound cases per day need routing that respects presence and capacity in real time. The workflow holds up at volume, with availability and capacity refreshing as cases close.

    First available agent routing alongside Omni-Channel

    Omni-ChannelService Cloud

    Omni-Channel handles channel-driven presence and routing for chat. The workflow extends the same concept to Email-to-Case and custom records, applying multi-factor logic that goes beyond presence alone.

    First available agent routing across multiple time zones

    Global teamsFollow-the-sun

    Global service teams use availability as a routing signal across time zones. The workflow respects presence and language skill together, so an inbound case routes to the agent who is online and qualified to take it.

    Built for service operations

    Routing that respects who can actually take the work.

    Cases land on agents who can actually take them.

    When the workflow respects live presence and capacity, cases stop sitting on agents who are offline or saturated. Customer wait times drop because the case lands on someone who can pick it up immediately.

    Workload stays balanced in real time.

    Capacity-aware routing prevents senior agents from absorbing everything while others sit idle. The team's throughput rises in proportion to active headcount, not in proportion to who happens to be next in rotation. The service ops team owns this workflow, with operations team adjusting rules as the business changes.

    Service ops sees the routing reality in standard reporting.

    Every routing decision is logged with the inputs: presence, capacity, skill match. Service leaders see why a case went where it did from a standard Salesforce report, not from a sit-down with each rep.

    PresenceCapacitySkill matchLanguageTime zoneTier eligibilityProduct lineWorkloadLast assigned

    Signals the first-available workflow evaluates

    Components of first-available routing

    Four elements every availability-aware routing workflow needs to cover.

    Ortoo Orchestrator provides the engine. Presence sources, capacity limits, and skill matrices are configured by service ops.

    Routing reads agent online status in real time, respecting Omni-Channel presence and other signals.

    // RULE CONFIG

    Tier-1 inbound, follow-the-sun coverage

    presence
    Omni-Channel + custom
    capacity
    Max 8 active per agent
    skills
    Product + language
    fallback
    Holding pool + manager alert
    refresh
    On accept, transfer, close
    audit
    All inputs logged

    IF agents available WITH skill match AND capacity > 0 THEN assign to least-loaded; ELSE fallback to holding pool.

    Case studies

    Teams running first-available routing as a workflow.

    Related use cases

    Adjacent service workflows in Ortoo Orchestrator.

    FAQ

    Common questions

    How is this different from native Salesforce round-robin?+

    Native round-robin assigns the next case to whoever is next in rotation, regardless of presence or capacity. The workflow inside Ortoo Orchestrator respects live agent status, capacity remaining, and skill match in the same routing decision.

    Does this work with Salesforce Omni-Channel presence?+

    Yes. The workflow reads Omni-Channel presence as one signal alongside capacity and skills. Cases route only to agents who are online with capacity to take them.

    What happens when no agent is available?+

    The workflow defines the fallback explicitly. Common patterns are queueing the case to a holding pool, escalating to a manager, or relaxing one criterion at a time until a match is found.

    Can the team set different rules per team or product line?+

    Yes. Each team or product line can have its own routing configuration, with different presence sources, capacity limits, and skill matrices. The workflow applies the rule per case based on the team.

    How is capacity tracked?+

    Per-agent workload limits are configured by the team and refreshed in real time as cases are accepted, transferred, or resolved. The next routing decision reflects current state.

    Can agents accept or decline an assigned case?+

    Yes. An accept-or-decline flow can be added as a configuration option for high-stakes cases. Declined cases route back to the workflow, which picks the next-best available agent.

    Is routing data reportable in standard Salesforce reporting?+

    Yes. Every routing decision is logged with the inputs: presence, capacity, skill match, and timestamp. Standard reports pick it up automatically.

    Route to who can take the work

    Map the availability-aware routing your service team should be running.

    Book a 30-minute conversation. We will walk through your current routing logic and where presence and capacity awareness remove the queue lag.

    Installs natively into Salesforce. Start with one workflow, expand to others as the team is ready. Pricing follows work completed, not token usage.