> For the complete documentation index, see [llms.txt](https://atlas.anywhere.now/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atlas.anywhere.now/channels-integrations/workforce-management/real-time-adherence-rules.md).

# Real-time adherence rules

Configure advanced real-time adherence rules for Workforce Management integrations.

Real-time adherence rules control whether the WFM plugin sends or suppresses specific adherence events for an agent state transition. Use these rules only when the default WFM event flow creates duplicate or unwanted provider events.

{% hint style="warning" %}
Incorrect adherence rules can suppress events for affected agents. Before changing rules in production, confirm the intended behavior with support or the implementation partner and keep a copy of the previous rule set.
{% endhint %}

## Behavior summary

The WFM plugin applies reason-code priority to avoid sending a reason code at a time when the provider may not accept it, such as during a call. In non-debug operation, the plugin delays event-bus listening for 10 minutes after plugin start.

Only one adherence rule can be active for an agent at a time. Invalid rules are ignored, but a valid rule with the wrong matching logic can continue suppressing events for an affected agent until the rule state is cleared by normal state transitions or by a support-confirmed recovery action.

{% hint style="info" %}
Do not treat a service restart as the standard recovery action for incorrect adherence rules. If events are suppressed, contact support to confirm the safe correction or recovery path.
{% endhint %}

## Rule format

Each rule must be on its own line in the `AdherenceRules` Plugin Setting.

```
PrecludePresence state|Code:Name=>Equality operatorPresence state|Code:Name
```

Example:

```
+Online|-1:InboundCall=>==Busy|-1:InboundCall
```

## Preclude operators

The preclude operator controls whether the first adherence state is sent.

| Operator | Meaning                                     |
| -------- | ------------------------------------------- |
| `+`      | The first adherence state must be sent.     |
| `~`      | The first adherence state must not be sent. |

The first adherence state follows the preclude operator. The rule then uses `=>` as a separator.

## Equality operators

The equality operator compares the following adherence state.

| Operator | Meaning                                                   |
| -------- | --------------------------------------------------------- |
| `==`     | Equals. The following adherence state must match.         |
| `!=`     | Not equals. The following adherence state must not match. |
| `<>`     | Not equals. The following adherence state must not match. |

## Adherence state format

An adherence state combines a presence state and a reason code.

| Element          | Description                                          |
| ---------------- | ---------------------------------------------------- |
| `Presence state` | Presence state, such as `Online` or `Busy`.          |
| `\|`             | Required separator between presence and reason code. |
| `Code`           | Reason-code ID.                                      |
| `:`              | Required separator between code and name.            |
| `Name`           | Reason-code display name.                            |

Either `Presence state` or `Code:Name` must be present. The `|` separator is still required.

## Presence states

Supported presence states for WFM rule matching are:

| Presence state |
| -------------- |
| `Online`       |
| `IdleOnline`   |
| `Busy`         |
| `IdleBusy`     |
| `DoNotDisturb` |
| `BeRightBack`  |
| `Away`         |
| `Offline`      |

## Reason-code priority

The WFM plugin creates and handles reason-code events in priority order.

| Code             | Name                        | Priority group | Description                                              |
| ---------------- | --------------------------- | -------------- | -------------------------------------------------------- |
| `-1`             | `UnknownCallType`           | Call           | Agent receives a call with an unknown type from the UCC. |
| `-1`             | `InboundCall`               | Call           | Agent receives an inbound call from the UCC.             |
| `-1`             | `OutboundCall`              | Call           | Agent starts an outbound call from the UCC.              |
| `-1`             | `DirectCall`                | Call           | Agent handles a direct call.                             |
| `-1`             | `Start`                     | Formal         | Agent signs in formally.                                 |
| `-1`             | `Stop`                      | Formal         | Agent signs out formally.                                |
| `-1`             | `WrapUp`                    | Wrap-up        | Agent enters wrap-up after a call has ended.             |
| `-1`             | `WrapUpEnd`                 | Wrap-up        | Agent wrap-up ends.                                      |
| `0`              | `Reset`                     | Reset          | Agent resets the reason code.                            |
| `<list-item-id>` | `<custom reason-code name>` | Custom         | Agent selects a configured custom reason code.           |

Custom reason codes come from UCC reason-code events. When the agent is no longer in a call or wrap-up, the selected custom reason code can be sent to the WFM provider.

## Configure `AdherenceRules`

1. Open the active UCC configuration source for the customer environment.
2. Open the `WFMPlugin` Plugin Settings.
3. Add or update `AdherenceRules`.
4. Enter one rule per line.
5. Save the configuration.
6. Apply the change through the current support or provisioning process for the environment.
7. Test with a limited set of agents before relying on the rule in production.

## Validate adherence rules

1. Trigger the agent state transition that should match the rule.
2. Confirm whether the WFM provider receives or suppresses the expected event.
3. Confirm that unrelated agent state transitions still send events.
4. Check for invalid-rule logging through the supported operational process if a rule does not behave as expected.
5. If events are unexpectedly suppressed, restore the previous rule set and contact support for the safe recovery path.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://atlas.anywhere.now/channels-integrations/workforce-management/real-time-adherence-rules.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.