Configuration reference

A single index of the settings most often asked about in support. Each entry lists the field name, where it lives in the workflow/agent JSON, the default, and a one-line description. If a question starts with “how do I…” or “what does X do?”, the answer probably starts here.

Triggering

Field	Where	Default	What it does
`trigger_type`	workflow	required	`SCHEDULED` (runs on a clock), `TRIGGERED` (runs when a PSA event matches), or `NONE` (chat agent — user-initiated). Fixed at creation — see below.
`entity_type`	workflow	`ticket`	What this workflow processes: `ticket`, `project_ticket`, `task`, `scheduled_entry`, `time_entry`. Shown in the builder as “What to process”. Fixed at creation — see below.
`callback_settings.target_changes`	workflow (TRIGGERED only)	required	List of PSA events that fire this workflow. Each entry is a `change_type` (e.g. ticket created, ticket updated) plus, for a field-change trigger, a `target_field` and optional `target_value`/`source_value`. `target_field` is limited to a fixed set of standard fields — status, priority, board/queue, ticket type. A custom field / UDF cannot be a `target_field`; to act on one, trigger on ticket created/updated and filter on it with a custom-field condition.
`callback_settings.run_only_once_per_entity`	workflow (TRIGGERED only)	`false`	If `true`, the workflow runs on each ticket at most once, ever. Used when you want a workflow to fire on creation but never again. It applies no matter what starts the run — a PSA event, another workflow’s Trigger Another Workflow action, or an agent’s Trigger Workflow tool. The one exception is a backfill, whose whole purpose is re-processing tickets you already handled. Enabling Bypass filter ticket conditions on the trigger action does not switch this off — that setting only skips the target’s ticket filters.
`process_sub_entities_only_once`	workflow	`false`	For sub-entities (time entries, notes, scheduled entries on a ticket): if `true`, Neo processes each sub-entity at most once. Without it, the same time entry can be re-processed every time its parent ticket changes.
`process_entities_sequentially`	workflow	`false`	If `true`, the workflow processes matched tickets one-by-one instead of in parallel. Slower but predictable when later steps depend on earlier ones. Incompatible with `REQUEST_TECHNICIAN_APPROVAL`.
`execution_order`	workflow	required	Integer position in the per-client ordering. Lower runs first when multiple workflows match the same event. Set by dragging the workflow on the Workflows page, or with Reorder.
`ignore_execution_order`	workflow	`true`	Inverse of the Obey Order toggle on the Workflows page — `ignore_execution_order: false` means Obey Order is on. While `true` (the default) the workflow ignores its position and runs in parallel with other matching workflows, so `execution_order` has no effect. Setting it to `false` also defers the ticket filter check until the earlier workflows finish, which is what lets a workflow filter on a field an earlier workflow fills in. See Dependencies.

entity_type and trigger_type can’t be changed after creation. Both controls are disabled in the builder once the workflow or agent exists, and an API update that sends a different value is rejected with a 400 naming the field. To process a different entity — or to switch between scheduled and triggered — create a new agent with the setting you want; the filters, conditions, and downstream actions are all shaped by these two fields, so there is no in-place conversion.

Before 2026-07-31, the “What to process” dropdown in the agent builder looked editable on an existing agent (the workflow builder always locked it). Changing it appeared to save but reverted on reload, and a later unrelated save could silently switch the agent back to processing tickets. If a customer reports an agent that “keeps resetting to Ticket”, that was this bug — it is fixed, and the three affected agents were corrected.

Scheduling (SCHEDULED workflows)

schedule object on the workflow.

Field	Default	What it does
`schedule.time_period`	`null`	Recurrence interval, e.g. `{ "interval": 1, "unit": "HOUR" }` for hourly, `{ "interval": 1, "unit": "DAY" }` for daily.
`schedule.start_datetimes`	`[]`	Specific clock times when the workflow runs (e.g. `08:00` and `15:00` for twice-daily).
`schedule.daily_execution_windows`	`null`	Per-weekday allowed run windows. Use this when a workflow should only run during business hours (e.g. Mon-Fri 08:30-17:30). Preferred over the deprecated `allowed_execution_hours` + `should_skip_weekends`.
`schedule.timezone`	`UTC`	IANA timezone for the schedule (e.g. `America/New_York`, `Europe/London`). All other schedule times are interpreted in this timezone.
`schedule.allowed_execution_hours`	`null`	Deprecated — replaced by `daily_execution_windows`. Single start/end window applied every day.
`schedule.should_skip_weekends`	`false`	Deprecated — set `daily_execution_windows` with weekday entries only instead.

Common gotcha — business-hours triggering: schedule.daily_execution_windows only constrains when the workflow itself runs. For TRIGGERED workflows (event-driven, not scheduled), the trigger fires whenever the PSA event matches — there is no “only trigger during business hours” knob today. If you need that, gate it with a filter on the ticket’s received_at or a deterministic business-hours filter.

Filters

The trigger filter lives on the first action, FIND_ENTITIES, at input_as_dict.ticket_conditions.conditions (for entity_type=ticket) or input_as_dict.time_entry_conditions.conditions (for entity_type=time_entry). conditions is a rule tree: a group with a combinator and a list of rules, where each rule is either a leaf (a single condition) or a nested group.

Field	Where	What it does
`combinator`	on each group	`and` or `or` — how that group’s `rules` combine. Mix AND/OR by nesting groups (a group can itself contain groups).
`rules`	on each group	The list of child conditions and/or nested groups.
`field`	a leaf rule	PSA field to match on — board, status, priority, type, sub-type, item, queue, company, owner, etc. (the field’s PSA name).
`operator`	a leaf rule	One of `=`, `!=`, `in`, `notIn`, `contains`, `doesNotContain`, `beginsWith`, `endsWith`, `null`, `notNull`, `<`, `>`, `<=`, `>=`.
`value`	a leaf rule	A single value, or a list for `in` / `notIn`.

Two optional sibling blocks sit next to conditions under ticket_conditions:

Field	What it does
`custom_field_conditions`	Filter on PSA custom fields / UDFs — its own `{ conditions: [{ field, operator, value }], combinator }` block, where `field` is the exact custom-field name.
`workload_conditions`	Restrict to tickets a technician logged service activity on within a date range.

Where a rule sits changes the logic. A company exclusion (companyID notIn […]) placed inside an or group only excludes when the other branches also miss — to exclude unconditionally it must be a top-level rule under the root and. AI filters. Alongside the deterministic rules above, a filter can include natural-language (“AI”) conditions — e.g. “ticket content is related to a printer issue” — and Neo can generate the deterministic rules for you from a description. These are configured in the filter builder; see Filter tickets. AI conditions are slower and consume credits per evaluation, so lead with deterministic rules and use them only for fuzzy matches. Common gotcha — NULL handling in ConnectWise filters: ConnectWise’s API uses SQL three-valued logic. A filter like Owner != "Alice" AND Owner != "Bob" silently drops tickets where Owner IS NULL, because NULL != "Alice" evaluates to NULL (not TRUE). To include unassigned tickets, use Owner IS NULL OR (Owner NOT IN ["Alice", "Bob"]) instead.

Test mode & re-running

Field	Where	Default	What it does
`agent_settings.test_mode`	agentic / conversational workflows	`false`	If `true`, the agent will not call tools with side effects (no PSA writes, no emails, no SMS). It adds an internal ticket note instead, describing what it would have done.
`agent_settings.report_test_via`	agentic / conversational workflows	`Internal Ticket Note`	Where the agent posts its dry-run report when `test_mode=true`: `Internal Ticket Note`, `Email to Internal Team`, `Teams Message to Internal Team`, or `Dashboard Message`.
`emulate_main_ticket_as_newly_created`	re-run dialog	`false`	When re-running, pretend the ticket was just created (so triage logic that gates on “newly created” runs again). The run sees only the ticket’s original description — no existing notes, time entries, or resolution — and is fully isolated from earlier runs: previously granted approvals don’t carry over, and an approval granted during the emulated run resumes that run only. Note this changes what the agent sees, not what it can do — combine with `test_mode` if writes must be suppressed too.
`ignore_previous_neo_executions`	re-run dialog	`false`	Same as “Start fresh” in the UI — the agent doesn’t see prior Neo executions on this ticket. Without it (“Continue previous”), the agent picks up where it left off.

Technician-in-the-Loop (TIL)

Field	Where	Default	What it does
`agent_settings.til_channel`	agentic / conversational workflows	`Teams` (AGENTIC) · `Chat` (CONVERSATIONAL)	Where TIL approval requests go: `Teams` (adaptive card sent to configured technicians) or `Chat` (approval card inline in the chat session). CONVERSATIONAL (chat) agents are pinned to `Chat` at create time — Teams delivery doesn’t apply because the requester is already in the chat.

Custom instructions

Field	Where	What it does
`agent_settings.custom_instructions`	agentic / conversational workflows	Free-text instructions that the agent loads as a system prompt. Use to encode MSP-specific naming, escalation paths, tone, prohibitions.
Action-level instructions	CHAINED_ACTIONS `Action.instructions`	Per-step instructions for an individual action (e.g. dispatch agent specifics). Layered on top of `custom_instructions`.
Skill files	`src/agents_v2/skills/prompts/`	Built-in skills the agent loads on demand (resolve-issue, end-user-communication, etc.).
Skill loader settings	`agent_settings`	Which built-in skills are enabled.

Notify-action delays

Notify actions support a configurable random delay so messages don’t all leave at the same second.

Field	Default	What it does
`include_random_delay`	`false`	If `true`, the notify action waits a random number of minutes before sending.
`min_range_delay_in_minutes`	`null`	Lower bound (in minutes) of the random delay.
`max_range_delay_in_minutes`	`null`	Upper bound (in minutes) of the random delay.

If include_random_delay=true but min and max are both 0/null, the delay is skipped (not an error).

Sub-entity callbacks

Field	Where	Default	What it does
`sleep_before_callback_processing_seconds`	client (not per-workflow)	`4`	Seconds Neo waits after receiving a PSA callback before kicking off the matched workflows. Gives the PSA time to settle (audit rows visible, related records consistent). Tune per-client only if your PSA needs longer.
`process_sub_entities_only_once`	workflow	`false`	See Triggering above.

Inbox notifications

Field	Where	What it does
`InboxException(send_email=…)`	source code	When `True`, dispatches an email + inbox card to the MSP admin (used for required action like missing settings, auth failures). When `False`, only an inbox card. Default is `False` — emails are reserved for MSP admin must act.
Dedup key	derived	`client_id + message_id`. If the same `InboxMessageId` can occur for distinct subjects (per end-client, per mailbox), use `compose_inbox_message_id(...)` to scope per-subject and avoid collapsing distinct failures into one message.

Credits

Concept	Detail
`CHAINED_ACTIONS` workflows	Each action sets its own `credits_consumed` (typically 1 per ticket). Sum = total per run.
`AGENTIC` entity-triggered	Billed at the max credit tier across the resolved toolbox (raw + auto-injected). Tiers: `BASIC`=1, `STANDARD`=2, `ADVANCED`=3.
`AGENTIC` conversational (no entities)	Billed as the sum of `tier × call_count` across each tool actually invoked.
Auto-injected tools	`MS_GRAPH_REQUEST` (when MS Graph perms non-disabled), `CW_PSA_REQUEST` (when CW PSA enabled), `SANDBOX_BASH` (always — every agent has a sandbox; `STANDARD` tier), and integration `*_REQUEST` tools all count toward credits — even though they don’t appear in the dashboard toolbox.
Generic API tool tier	`STANDARD` when all enabled perms are READ_ONLY; `ADVANCED` when any perm is READ_WRITE. PowerShell tools stay `ADVANCED` regardless.

Field	Where	What it does
`created_by_user`	workflow	Who owns the workflow. Required to view/edit unless the workflow is shared (or unless you are a super-admin).
`version_timestamp`	workflow	Optimistic-lock version. PUT requests must include the version they’re editing against; mismatches return `409 Conflict`.
`state`	workflow	`ENABLED`, `DISABLED`, or `DELETED`. Disabled workflows don’t run; deleted are tombstoned.
`group_name`, `group_order`	workflow	Purely organizational folder + position within the folder. Doesn’t affect execution.

Getting started

Core

Triggered & Scheduled Agents

Chat Agents

Integrations

Product

Workflows

Customizing Neo

Configuration reference

Triggering

Scheduling (SCHEDULED workflows)

Filters

Test mode & re-running

Technician-in-the-Loop (TIL)

Custom instructions

Notify-action delays

Sub-entity callbacks

Inbox notifications

Credits

See also

​Triggering

​Scheduling (SCHEDULED workflows)

​Filters

​Test mode & re-running

​Technician-in-the-Loop (TIL)

​Custom instructions

​Notify-action delays

​Sub-entity callbacks

​Inbox notifications

​Credits

​Versioning & sharing

​See also

Triggering

Scheduling (SCHEDULED workflows)

Filters

Test mode & re-running

Technician-in-the-Loop (TIL)

Custom instructions

Notify-action delays

Sub-entity callbacks

Inbox notifications

Credits

Versioning & sharing

See also