Job Router key concepts


Functionality described on this section is currently in private preview. Private preview includes access to SDKs and documentation for testing purposes that are not yet available publicly. Apply to become an early adopter by filling out the form for preview access to Azure Communication Services.

Azure Communication Services Job Router solves the problem of matching supply with demand.

A real-world example of this is matching call center agents (supply) to incoming support calls (demand).


A Job is a unit of work (demand), which must be routed to an available Worker (supply).

A real-world example is an incoming call or chat in the context of a call center.

Job lifecycle

  1. Your application submits a Job via the Job Router SDK.
  2. (Optional) If you specified a Classification Policy, the Job is classified and a JobClassified Event is sent via Event Grid.
  3. The Job is added to the queue that you specified or that was determined by the Classification Policy, and a JobQueued Event is sent via Event Grid.
  4. Job Router searches for matching workers based upon any Label selectors and the Distribution Policy if the queue.
  5. When a matching Worker is found, an Offer is issued and an OfferIssued Event is sent.
  6. Your application can accept the Offer via the SDK and the Job will be removed from the queue and an OfferAccepted Event will be sent that contains an assignmentId.
  7. Once the Worker has completed the Job, the SDK can be used to complete and close it, using the assignmentId. This will free the Worker up to take on the next Job.

Diagram that shows the Job lifecycle.


A Worker is the supply available to handle a Job. When you use the SDK to register a Worker to receive jobs, you can specify:

  • One or more queues to listen on.
  • The number of concurrent jobs per Channel that the Worker can handle.
  • A set of Labels that can be used to group and select workers.

A real-world example is an agent in a call center.


A Queue is an ordered list of jobs, that are waiting to be served to a worker. Workers register with a queue to receive work from it.

A real-world example is a call queue in a call center.


A Channel is a grouping of jobs by some type. When a worker registers to receive work, they must also specify for which channels they can handle work, and how much of each can they handle concurrently. Channels are just a string discriminator and aren't explicitly created.

Real-world examples are voice calls or chats in a call center.


An Offer is extended by Job Router to a worker to handle a particular job when it determines a match. You can either accept or decline the offer with the JobRouter SDK. If you ignore the offer, it expires according to the time to live configured on the Distribution Policy.

A real-world example is the ringing of an agent in a call center.

Offer acceptance flow

  1. When Job Router finds a matching Worker for a Job, it creates an Offer and sends an OfferIssued Event via Event Grid.
  2. The Offer is accepted via the Job Router API.
  3. The job is removed from the queue and assigned to the worker.
  4. Job Router sends an OfferAccepted Event.
  5. Any existing offers to other workers for this same job will be revoked and an OfferRevoked Event will be sent.

Offer decline flow

  1. When Job Router finds a matching Worker for a Job, it creates an Offer and sends an OfferIssued Event via Event Grid.
  2. The Offer is declined via the Job Router API.
  3. The Offer is removed from the worker, opening up capacity for another Offer for a different job.
  4. Job Router sends an OfferDeclined Event.
  5. Job Router won't reoffer the declined Offer to the worker unless they deregister and re-register.

Offer expiry flow

  1. When Job Router finds a matching Worker for a Job, it creates an Offer and sends an OfferIssued Event via Event Grid.
  2. The Offer is not accepted or declined within the TTL period defined by the Distribution Policy.
  3. Job Router will expire the Offer and an OfferExpired Event will be sent.
  4. The worker is considered unavailable and will be automatically deregistered.
  5. A WorkerDeregistered Event will be sent.

Distribution Policy

A Distribution Policy is a configuration set that controls how jobs in a queue are distributed to workers registered with that queue. This configuration includes:

  • How long an Offer is valid before it expires.
  • The distribution mode, which define the order in which workers are picked when there are multiple available.
  • How many concurrent offers can there be for a given job.

Distribution modes

The three types of modes are

  • Round Robin: Workers are ordered by Id and the next worker after the previous one that got an offer is picked.
  • Longest Idle: The worker that has not been working on a job for the longest.
  • Best Worker: The workers that are best able to handle the job are picked first. The logic to rank Workers can be customized, with an expression or Azure function to compare two workers. See example


You can attach labels to workers, jobs, and queues. Labels are key value pairs that can be of string, number, or boolean data types.

A real-world example is the skill level of a particular worker or the team or geographic location.

Label selectors

Label selectors can be attached to a job in order to target a subset of workers on the queue.

A real-world example is a condition on an incoming call that the agent must have a minimum level of knowledge of a particular product.

Classification policy

A classification policy can be used to programmatically select a queue, determine job priority, or attach worker label selectors to a job.

Exception policy

An exception policy controls the behavior of a Job based on a trigger and executes a desired action. The exception policy is attached to a Queue so it can control the behavior of Jobs in the Queue.

Next steps