Automation logic decides what should happen next in a customer conversation. It can combine deterministic rules, AI, workflows, conversation state, and connected systems, then tell Salted which supported actions to perform.
In Salted configuration, integration, API, and SDK documentation, this automation logic is called Your Logic. The technical name describes the configured interface; it is not a separate product or a required visual workflow builder.
The event, decision, action loop
A typical turn follows this sequence:
- A customer, human agent, AI agent, external participant, channel, or connected integration changes the conversation.
- Salted creates a conversation event with the relevant trigger and context.
- Salted sends the event to the configured automation implementation in the order it occurred for that conversation.
- The automation logic evaluates the event using rules, AI, state, knowledge, customer data, and connected systems.
- It returns one or more supported actions.
- Salted performs those actions and updates the conversation.
The loop repeats as the customer and other participants continue the interaction.
What automation logic can decide
Depending on the implementation and supported action contract, automation logic can decide:
- what to tell or ask the customer,
- whether to use a menu, free text, or another supported interaction,
- which customer or case information to retrieve,
- which permitted business action to perform,
- whether a human decision is required,
- whether to request help from a human agent,
- whether to invite an external expert,
- how to classify and route the conversation,
- what information, suggested reply, or actions to show in Agent Desktop,
- whether to remain silent while a human owns the interaction,
- whether AI can continue after the human contribution ends,
- when the conversation should be completed.
A production implementation should make these decisions according to explicit policy, permissions, and system state. Prompts can guide behavior, but hard operational boundaries should be enforced by deterministic controls where appropriate.
Events provide the context
Conversation events describe what happened in or around the interaction. Depending on the contract and channel, events can represent customer messages or answers, participant actions, lifecycle changes, completed engagements, external callbacks, reviews, and other supported triggers.
Salted includes conversation context with the event so the implementation can reason about the current interaction. The exact payload, fields, and trigger names are defined in the Your Logic Events technical reference and must not be paraphrased in implementation code.
Actions tell Salted what to do
Actions are the instructions returned to Salted. Depending on the current contract, they can cover customer messages and questions, internal notes, help requests, participant invitations, conversation updates, customer updates, files, channel-specific communication, engagement control, completion, and other supported operations.
Actions can also affect the human workspace. For example, automation logic can provide a suggested reply, show information, change the availability of actions, or update routing and disposition data.
Human oversight and takeover
Authorized supervisors can monitor ongoing AI-led conversations in Live Conversations without first joining them. They can inspect the transcript, participants, alerts, routing, and available context. When intervention is needed, they can join or assign a human agent, take over customer communication, or contribute a bounded decision.
Automation logic should define what happens when a human joins:
- whether AI pauses or remains silent,
- whether it continues to provide assistance,
- how ownership and routing change,
- what happens when the human leaves,
- whether AI can resume the workflow.
Monitoring and joining are different operational states. Viewing does not create a human-agent engagement; joining does.
Conversation state and ordering
Salted sequences events within an individual conversation so the configured automation can process them in order. An implementation can also maintain its own business state or store supported custom conversation data for use in later turns.
Different conversations from the same customer can still happen at the same time. The implementation must therefore handle concurrency safely when it reads or changes customer-level data in external systems.
Failure and fallback behavior
A production implementation should define:
- response deadlines and timeout handling,
- what Salted should do when the automation is unavailable or returns an invalid response,
- which requests should fall back to a human,
- what the customer should be told while waiting,
- how retried or asynchronous work is correlated with the original conversation,
- which operations must be idempotent or protected against duplicate execution.
Use the current technical guides for exact timeout, authentication, sequencing, and fallback behavior.
Ways to implement the automation
The automation logic can be implemented through:
- a custom webhook service,
- the Conversations SDK,
- custom code in a supported runtime,
- a workflow or orchestration tool,
- AI agents and tool-calling logic,
- a combination of deterministic and generative components.
These are implementation mechanisms. In the Salted technical contract, the configured automation interface is called Your Logic.
Technical documentation
- For exact incoming events, see Your Logic Events.
- For exact outgoing actions, see Your Logic Actions.
- For the integration model, see Your Logic Integration Guide.
- For practical implementation guidance, see Your Logic Implementation Tips.
- For example response patterns, see Your Logic Response Examples.
- For the SDK overview, see Conversations SDK.
Availability
The actions, events, SDK features, channels, and integration patterns available to a specific deployment depend on the current production contract and account configuration. Treat examples and private-library primitives as evidence of possible implementation patterns, not automatic general availability.