> ## Documentation Index > Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt > Use this file to discover all available pages before exploring further. # Configuration reference > Every workflow, agent, and trigger setting in one place — what each field does, where it lives, default values, and common gotchas (custom-field filters, business hours, delays, test mode, TIL channel, sub-entity dedup, credits). 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](/chat-agents/overview) — user-initiated). | | `entity_type` | workflow | `ticket` | What this workflow processes: `ticket`, `project_ticket`, `task`, `scheduled_entry`, `time_entry`. | | `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. | | `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. | | `ignore_execution_order` | workflow | `true` | If `true`, this workflow ignores ordering and runs in parallel with other matching workflows. Set `false` only when ordering is load-bearing. | ## 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 Filters live inside the first action (`FIND_ENTITIES.input.filter_conditions`). | Field | Where | What it does | | ------------------------------ | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `field_name` | a single filter condition | PSA field to match on — board, status, priority, type, sub-type, item, queue, company, owner, or any custom field (use the PSA's exact custom-field name). | | `operator` | a single filter condition | `EQUALS`, `NOT_EQUALS`, `IN`, `NOT_IN`, `IS_NULL`, `IS_NOT_NULL`, `CONTAINS`, etc. | | `value` / `values` | a single filter condition | Single value or list, depending on operator. | | `logical_operator` | between conditions | `AND` (default) or `OR` for combining multiple conditions. Custom-field filters and standard fields can be mixed freely. | | AI filter (`ai_filter_prompt`) | filter conditions | Natural-language predicate — Neo evaluates the ticket against your description (e.g. *"ticket is about a printer issue"*). Slower and consumes credits per evaluation; use deterministic filters first and AI filters 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). | | `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](/chat-agents/overview)) 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. | ## Versioning & sharing | 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. | ## See also * [Filter tickets](/core/filter-tickets) — how to combine deterministic and AI filters. * [Triggers & Schedules](/core/triggers-and-schedules/intro) — choosing between `SCHEDULED` and `TRIGGERED`. * [Workflows vs Agents](/core/workflows) — when to pick `CHAINED_ACTIONS` vs `AGENTIC`. * [Actions](/core/actions) — what each action does and which credit it costs.