Advanced automation

The Advanced hub contains the capabilities for connecting Nexor to other systems, routing leads, and running automation outside the normal conversation flow. Open it from Advanced in the sidebar. Its configuration is organization-wide unless a tool is explicitly assigned to one agent.

​

Choose the right capability

​

Webhooks

Webhooks send outbound HTTP notifications when a supported status, meeting, or outreach event occurs. Each request carries an HMAC signature in X-Nexor-Signature, allowing the receiver to verify that the payload came from Nexor. Use a webhook when your system only needs the event. If you need to filter, transform, branch, call multiple services, or write data back to the lead, use a Cloud Function. Before enabling a webhook:

1. configure its URL and events;
2. store the signing secret in the receiving system;
3. verify the signature against the unmodified body;
4. return a 2xx response quickly; and
5. process idempotently because a delivery may be retried.

See Webhook events, Verifying signatures, and Retries and errors.

​

MCP Tools

An MCP tool describes an HTTP call the agent can make during a conversation. Its definition includes a name, description, method, URL, JSON parameter schema, headers, authentication, timeout, and response-handling rules. Tools have two scopes:

• Shared catalog: a reusable tool that can be assigned to several agents.
• Agent tool: a one-off integration available only to that agent.

After assignment, you can let the agent call it when needed, run it automatically when a lead enters, limit it to particular stages, or execute it automatically when a lead reaches a stage. See Agent-level advanced settings for these policies. To manage tools through the API, see Client Tools and Workflow Tools.

​

Background Jobs

Background Jobs run structured automations over leads. They can be triggered by cron, by a supported event, or only through the API. A job combines:

• filters by agent, status, and lead data;
• conditions on metadata, variables, or tags;
• actions such as assigning or transferring an agent, changing status, sending a WhatsApp template, or calling an external API;
• per-cycle lead caps, cooldowns, and rate limits;
• exclusions for human-taken-over leads or paused agents;
• dry-run mode and per-execution logs.

Start in Dry run, inspect how many leads would be candidates and which actions would run, then activate the job with conservative limits. Use Run now only after validating the same configuration. See the Background Jobs API to create, run, and inspect jobs programmatically.

​

Pre-processors

Pre-processors route leads before they enter an agent. Each processor has ordered rules and a default agent:

1. it receives a lead through the processor endpoint;
2. it evaluates rules from top to bottom using top-level fields and metadata;
3. it uses the first matching rule; and
4. it sends the lead to the default agent when no rule matches.

Use them to distribute by country, business line, campaign, product, account size, or any data available when the lead is created. The endpoint also accepts batches; each lead is evaluated independently and can reach a different agent. See Create a Pre-processor, Create a rule, and Route a lead.

​

Cloud Functions

Cloud Functions run isolated JavaScript when an agent event occurs. Code receives the payload in ctx, can inspect lead, make requests with axios or fetch, write logs, return JSON, and propose changes with updateLead or updateMetadata. Each function listens to one trigger. Simulate the payload, save to deploy, and inspect executions before activating it. HTTP calls made by a manual test are real even though proposed lead changes are not applied. See the complete Cloud Functions guide for triggers, runtime, limits, examples, and logs.

​

Scheduled Functions

Scheduled Functions run isolated JavaScript on a cron expression and timezone. Each execution queries a lead cohort, exposes batch context to the code, and records its result and logs. Use one when the logic is too specific for a Background Job: aggregations, custom payloads, coordinated calls to multiple APIs, or rules that are clearer in JavaScript. Before enabling a function:

1. define the cron and timezone;
2. narrow the query to the required cohort;
3. preview the included leads;
4. test with safe credentials and endpoints; and
5. inspect logs and design writes to be idempotent.

​

Environment Variables

Environment Variables store secrets shared by Cloud Functions, Scheduled Functions, and MCP tools. Functions read them as env.NAME, for example env.CRM_API_TOKEN. MCP tool authentication, headers, and query parameters reference them as {{env.NAME}}. Values are write-only: after a secret is saved, the interface shows its name but never its value. Replacing a variable requires entering the complete value again. Names must start with an uppercase letter and contain only uppercase letters, numbers, and underscores. An organization can store up to 128 variables, with names up to 64 characters and values up to 5 KiB.