Operator actions
Define safe tasks that Polaris Operator can run or prepare for your team.
An action is a task or process that Polaris Operator can run automatically or prepare for human review.
It turns a conversation into concrete work, such as creating a lead, updating a booking, sending a notification, calling a webhook or preparing a task for a team.
Common examples
- Create a lead for sales follow-up.
- Prepare an appointment request.
- Create a support task.
- Send an internal notification.
- Update a booking status.
- Connect the conversation to another tool.
How to configure them
- Define the outcome the action should create.
- List the minimum information it needs.
- Decide whether human approval is required.
- Test the flow with real data.
- Publish first for a low-risk case.
- Review results before expanding usage.
Tools and execution rules
A tool is a specific capability Operator can use when a conversation needs to become work. Enabling a tool lets Polaris prepare or run that action in the workspace, within the configured rules.
Execution rules define how a tool behaves:
- Human approval: Operator prepares the action, then waits for a person to approve it before running.
- Immediate execution: the action runs right away when policy allows it.
- Background execution: the action is queued as a job and can continue outside the conversation turn.
- Business hours: the action can run only inside a configured time window.
Recommended presets
In Operator -> Tools -> Configure, Polaris provides presets so most users do not need to edit JSON:
- Safe default: requires human approval and runs in the background. This is the recommended starting point.
- Internal low risk: runs immediately without approval. Use only for low-impact internal actions, such as tagging conversations in a controlled workspace.
- Business hours: allows execution only inside the configured schedule and requires approval.
Presets update the rules on screen, but they do not save automatically. You still need to click Save changes.
External integrations
Tools like generic_webhook and send_email require extra care because they can send data outside Polaris.
generic_webhook calls an external HTTPS endpoint with POST. It can use secrets with the {{secret:secret_name}} syntax so credentials are not exposed. For safety, webhooks always require approval and background execution, even if the policy says otherwise.
Non-technical users should not edit advanced JSON, headers, payloads or secrets without technical support. Use basic mode whenever possible.
Advanced configuration
The advanced section shows Policy JSON for technical administrators.
Policy JSON controls real rules such as approval, execution mode and business hours. Advanced tool configuration is reserved for future phases and is not required for non-technical users.
Best practices
Design each action with a clear outcome. The more specific it is, the easier it is to test, review and keep under control.
- Name the action by the result it creates.
- Ask only for the information required to run it.
- Avoid actions that are too broad or ambiguous.
- Use approvals when the action may affect a customer, appointment or important record.
- Design actions so they can run safely without creating duplicate results.
Action examples
| Action | Typical use |
|---|---|
| create_lead | Prospect capture |
| booking_request | Appointment request |
| send_notification | Internal alerts |
| create_support_task | Support follow-up |
| update_booking_status | Booking changes |
Safety and traceability
Operator should not run sensitive actions blindly. Polaris records important actions so your team can review what was attempted, when it happened and what the result was.
This helps your team stay in control when automation fails, waits for review or needs a person to step in.
When something fails
Every action should end with a clear status so the team knows whether it completed, failed or needs review.
If an action cannot be completed, Polaris should keep enough context for a person to continue without starting over.
What to avoid
- Broad actions like “solve everything”.
- Asking for information that is not required.
- Running sensitive actions without approval.
- Automating before reviewing real results.
Related modules
Actions often work with Chatbots, Approvals, Jobs, Booking and channels like WhatsApp or Web Widget.
The chatbot detects the need, Operator prepares the action, Approvals protect sensitive decisions and Jobs can continue work in the background.