Agreement Agent (ConnectWise)

1. Select Which Boards Should Trigger This Agent

This setting defines where the agent is allowed to run.

Select one or more boards where the Agent should evaluate tickets. Only tickets that exist on these boards will be considered.

If all boards are selected, the agent may run on tickets from any board, provided all other trigger conditions are met. The agent is set to run on all boards by default.

This setting does not determine what the agent changes. It only controls eligibility based on board placement.

2. Select Which Companies Should Trigger This Agent

This setting defines which existing company values are eligible for urgency, impact, and priority evaluation.

By default, if no companies are selected, the Agent will evaluate tickets from all companies, provided all other trigger conditions are met.

When companies are selected, the agent will only evaluate tickets whose initial Company field matches one of the selected values.

This is commonly used when:

• Tickets are created under placeholder companies such as Catchall or Unknown

• Certain company records are known to produce unreliable urgency or priority values at ticket creation

• Automated severity classification should apply only to specific customers or service tiers

If all companies are selected, the behavior is equivalent to leaving the setting empty.

Important Clarification

This setting is evaluated against the company value present on the ticket when it first enters your ConnectWise environment.

In practice, the agent reads the ticket’s initial Company field at creation time and uses that value to determine eligibility. Any company changes made later in the ticket lifecycle do not affect whether this agent runs.

This ensures severity classification remains predictable and does not change retroactively as company assignments are updated.

3. Optional: Exclude Companies From Triggering This Agent

This setting defines hard exclusions.

Tickets whose current Company value matches any excluded company will never be evaluated, even if:

• The board condition is met

• The status condition is met

• The company is otherwise included in the trigger list

Common use cases include:

• Your internal MSP company

• Vendor or distributor records

• Administrative or system level companies

Exclusions take precedence over company trigger selections.

4. Optional: Add Standard Operating Procedure (SOP) Instructions

SOPs provide behavioral rules and guardrails that the agent must follow.

SOPs are evaluated after trigger conditions are met but before any prediction or change is applied.

SOPs can be used to:

• Restrict when the agent is allowed to change the company

• Prevent reassignment in specific scenarios

• Force or exclude specific company outcomes

• Add business context that cannot be captured by filters alone

SOPs are optional. If no SOP is provided, the agent relies on board scope, company triggers, exclusions, historical patterns, and ticket context.

If an SOP applies and blocks execution, the agent will not modify the ticket. The decision and reason are recorded in the workflow logs.

How SOPs Affect Execution

SOPs are evaluated before the agent applies any inferred prediction.

If an SOP applies, it may:

• Explicitly allow the agent to proceed

• Restrict the agent from making any change

• Force a specific company assignment

• Exclude certain companies from reassignment

If an SOP blocks execution, the agent will not modify the ticket, even if all other trigger conditions are met. The outcome is recorded in the workflow logs.

1. Override Existing Field Value

By default, the Agreement Agent takes a conservative approach to agreement assignment.

If an agreement is already set on a ticket, the agent will not overwrite it. This safeguard is in place to avoid unintentionally changing agreements that were intentionally applied by your team or by existing automation.

However, many MSPs automatically assign a default agreement as soon as a ticket is created, even when that agreement is not always correct. In these environments, the Agreement Agent may skip evaluation because it detects that an agreement is already present.

To support both workflows, the Agreement Agent includes a configuration toggle that allows you to control whether existing agreements can be corrected.

When Disabled (Default)

• The agent assigns an agreement only if the Agreement field is empty

• Tickets that already have an agreement will not be modified

This option is best for MSPs that trust their initial agreement assignment or want to avoid any automated overrides.

When Enabled

• The agent is allowed to overwrite an existing agreement

• The agent re-evaluates whether the current agreement is correct and replaces it when necessary

This option is best for MSPs that use placeholder or auto-assigned agreements at ticket creation and want zofiQ to apply the correct agreement based on ticket context.

1. Historical Urgency Impact Priority Assignments

The agent learns from how your team has historically classified urgency, impact, and priority in ConnectWise.

Past severity decisions for similar tickets help establish patterns that reflect how your organization typically assesses criticality. This allows classifications to align with real-world operational behavior rather than generic or default SLA assumptions.

Historical patterns inform severity decisions, but they are evaluated alongside ticket context and SOP rules rather than acting in isolation.

2. Ticket Context

At runtime, the agent evaluates the full ticket context, including:

• Summary

• Description

• Notes

• Requester and sender details

Rather than relying on a single keyword or field, the agent considers how all available information relates to urgency, scope of impact, and required response time. This allows it to assess severity even when individual fields are incomplete, inconsistent, or ambiguous.

No single field is treated as authoritative on its own.

3. Standard Operating Procedures (SOP) Rules

SOPs act as high-priority guidance for the Agent.

When an SOP applies, it is evaluated before inferred signals from historical data and ticket context and is treated as the strongest input in the decision process. In the vast majority of cases, SOP instructions are followed explicitly and drive the final company assignment.

SOPs can be used to allow, restrict, or strongly bias company assignments based on your defined operational rules. Both positive and negative SOPs consistently outweigh inferred predictions and are designed to enforce your operational intent.

While the Agent evaluates SOPs alongside full ticket context, cases where an applicable SOP is not followed are rare and typically tied to ambiguous or conflicting ticket signals. All such decisions are visible in workflow logs for review.