Amazon Connect splits Task and Email concurrency into up to five workload types per channel

According to a write-up on dev.to, a Task or Email contact now takes four steps to reach an agent ^[10][14]:

1. A flow's Set contact attributes block, or an UpdateContact call for a task classified outside the flow, writes a value to connect:WorkloadType ^[10]. 2. The contact enters a queue ^[14]. 3. Routing looks for an agent whose routing profile has a row for that value and a free slot ^[14]. 4. That row's concurrency and cross-channel behavior govern the agent's slot ^[14].

Step 3 is where it breaks. A value with no matching row leaves the contact in the queue, and nothing raises an error ^[14]. The write-up's monitoring design watches for that case with an alarm on oldest contact age, alongside GetCurrentMetricData slot counts and a CloudWatch alarm when ConcurrentEmailsPercentage passes 80% ^[15].

The gap between taxonomy and configuration is wide. The attribute accepts up to 500 values, and a routing profile takes five rows per channel ^[6][7]. One profile can cover at most 1% of a full taxonomy on a given channel ^[21]. "The big taxonomy does not fit the configuration," the write-up says ^[18]. The classifier can be a business rule, a lookup or a model ^[16]. Any value it writes outside a profile's rows takes the silent path ^[14]. The write-up says this failure mode deserves an audit before any pilot ^[19]. I'd run that audit as a join: every value the flows and classifiers can write, against the rows of every profile serving those queues.

Each row takes a concurrency from 1 to 10, and a channel's rows share 10 slots in total ^[8]. The write-up's example puts Dispute-Review at 1 with nothing else allowed, and Statement-Request at 3 ^[2]. Those two rows use 4 of the channel's 10 slots ^[20]. Even the worked example disagrees with itself. The text has the Statement-Request agent still accepting a chat ^[2]. The diagram marks the same row as same-channel only ^[3]. That middle option of the three blocks other channels ^[1].

The concurrency API has a separate gap. Per the write-up, the MediaConcurrency object documents Channel, Concurrency and CrossChannelBehavior, with no workload-type field ^[9]. Enabling workload types on a channel disables channel-level concurrency there, and the old fields go inactive ^[12]. So the only fields the API documents are the ones that stop governing routing once a channel switches ^[22]. In my view, a script that rebuilds agent capacity from that object will report a ceiling that no longer applies ^[22]. The write-up does not say whether the new rows will appear in the API.

Classification also has a rate ceiling. The write-up's diagram lists UpdateContact at 10 transactions per second, with a burst of 15 ^[11]. Sustained, that comes to 600 task classifications a minute through the API ^[23].

The migration design is careful work. A contact with no explicit workload type falls back to its subtype, so a partial migration leaves existing traffic alone as long as a row exists for that subtype ^[13]. Teams can enable the feature channel by channel and queue by queue ^[13]. The staffing gain is real for email. The old model's math "only balanced on the average, never on the tail," the write-up says ^[17]. Email queues with handle times between 2 and 90 minutes now balance on up to five numbers instead of one ^[24].