Studio overview
Understand Studio as the system builder for real business operations: agents, workflows, channels, integrations, tables, resources, logs, analytics, and publishing.
Use this Studio state to connect the product UI to a real business operation: customer signal, agent behavior, workflow path, channel, CRM context, and review outcome.
Follow the real configuration that turns an operation into a system.
These captures favor full, readable product states: agents, workflows, channels, logs, analytics, and publishing controls without floating labels or artificial step boxes.
Use this Studio state to connect the product UI to a real business operation: customer signal, agent behavior, workflow path, channel, CRM context, and review outcome.
Use this Studio state to connect the product UI to a real business operation: customer signal, agent behavior, workflow path, channel, CRM context, and review outcome.
Summary
Understand Studio as the system builder for real business operations: agents, workflows, channels, integrations, tables, resources, logs, analytics, and publishing.
Concepts covered
Step breakdown
- Choose the business operationStart with a real outcome: qualify WhatsApp leads, route support, update CRM, notify Sales, or follow up after a meeting.
- Build the system piecesConfigure the agent, workflow nodes, channels, integrations, tables, resources, and CRM context required for that outcome.
- Test and publishUse Logs, Analytics, Draft/Live state, and connected surfaces to verify what happened before the system runs on customers.
What Studio is
Studio is where teams build the operational systems that run inside Frontline. It is not a course area and not only a workflow diagram: it is where agents, workflows, channels, integrations, tables, resources, logs, analytics, and publishing controls become a real business process.
Use Studio when you want Frontline to do work from a customer or internal signal: respond to a WhatsApp lead, qualify it, update CRM, notify Sales, create follow-up, route support, or connect an external system.
How the pieces connect
Channels receive customer communication such as WhatsApp, Instagram, Messenger, live chat, or other connected surfaces.
Workflows turn those signals into an operating path: trigger, data cleanup, agent step, conditional routing, message, CRM update, webhook, task, or handoff.
Agent Builder defines the AI teammate that can classify, answer, capture data, or prepare work. The agent uses instructions, model/provider selection, knowledge, tools, playbooks, channels, and workflow responsibilities.
CRM gives the system customer memory. Tables and Resources give it structured context and approved knowledge. Logs and Analytics prove what happened. Max Activity and To-do's help teammates review follow-up.
Operational examples
Sales: a WhatsApp lead arrives, Studio identifies or creates the Person in CRM, asks the Sales Agent to qualify intent, routes by fit, sends a follow-up, notifies Sales, and records the activity for review.
Support: a customer message arrives, Studio checks ticket context, asks Support Agent to classify urgency, sends a safe reply or escalates to a teammate, and keeps Logs available for debugging.
Marketing: an Instagram or campaign signal enters a workflow, Studio enriches the contact, segments the lead, updates CRM, and triggers a follow-up path.
HR: a candidate or employee signal enters a workflow, Studio compares it with role criteria or policy resources, prepares a recruiter or People-team task, and keeps the handoff inspectable.
What users build here
Agents: Sales Agent, HR Agent, Support Agent, and Marketing Agent with model/provider, instructions, knowledge, tools, playbooks, workflows, channels, conversations, and analytics.
Workflows: Lead Re-engagement, scheduled pipeline review, support triage, follow-up, enrichment, webhook, and CRM update systems.
Channels: the customer communication surfaces that start or continue the work.
Integrations, Tables, and Resources: the external tools, structured operating data, and approved knowledge that keep automation grounded.
How to know Studio is working
A working Studio system has a clear trigger, readable nodes, explicit routing, tested Logs, useful Analytics, a safe Draft/Live state, and a human review path.
The user should be able to explain the operation in one sentence: when this signal happens, Studio does these steps, updates this context, notifies this owner, and leaves this evidence.
Operational playbook
Use Studio overview as part of the Frontline Studio Overview operating loop: inspect the current product state, confirm the source context, and decide what should happen next.
The goal is not to memorize screens. The goal is to understand how the product surface supports repeatable work, AI assistance, and accountable handoff.
Best practices
Start with the operational job before changing configuration. Name the owner, define the trigger or source context, and decide how the result should be reviewed.
Prefer narrow, inspectable setups over broad automation. Teammates should be able to explain why the system took an action from the visible product state.
Troubleshooting
If the result does not match expectation, check the source context first, then permissions, connected integrations, required fields, workflow logs, and any AI-generated output used by downstream steps.
When in doubt, compare the latest product state with the related record, activity, or workflow execution so debugging starts from evidence rather than guesswork.
Transcript
Open searchable transcript
FAQs
What is Studio overview?
Understand Studio as the system builder for real business operations: agents, workflows, channels, integrations, tables, resources, logs, analytics, and publishing.
Why start with this overview?
The overview explains how this product area works before users enter a specific screen walkthrough or implementation blueprint.
How does this connect to the Frontline ecosystem?
Each overview shows how Studio, CRM, Max, Channels, AI agents, workflows, and Activity connect into one operating system.
How should this page fit into onboarding?
Use it to understand the product surface, inspect real UI states, and connect the concept to daily operating workflows before configuring production behavior.
What should I verify before using this in production?
Verify ownership, permissions, source context, failure behavior, and the handoff path so teammates can trust what the system does next.