41 Sample Workspace and Demo Flows

41.1 Overview

Status: This page is technical reference for the Automations 0.92.1 implementation. It does not claim customer availability; staging verification and production enablement are separate gates.

This guide describes prerequisites and examples for trying Sophea Automations in a configured sample Workspace. Use the examples to configure triggers, actions, and mappings, then inspect step outputs and flow runs.

41.2 Sample Workspace Configuration

41.2.1 Prerequisites

An operator-provisioned Automations platform with the dedicated workload and Portal launch integration configured.
An active Portal Workspace with Automations enabled, and an active member who can open the selected Workspace.
A visible CHAT model and Workspace default configured through platform model governance.
Real indexed documents accessible to the user who will run the knowledge flows.
An enabled, invokable Nous agent for the agent example.
Nous SMTP configured, plus a recipient mailbox you can read to check actual delivery.

41.2.2 Recommended setup

For a complete demo, prepare the content and services each example actually uses:

Knowledge base: index the remote-work policy used in Demo 1 and any other documents needed by your queries. Confirm they are accessible to the user running each flow.
AI model: configure a visible CHAT model and Workspace default through platform model governance. Automations resolves workspace_default against Nous’s live Workspace default at run time; no workspace_default alias needs to be configured in LiteLLM.
Agent: enable an agent that can be invoked by the selected Workspace and configure its required tools, such as web search, for Demo 4.
Email: configure the Nous SMTP prerequisites and use a mailbox you can read. A configured SMTP server or a sent action result alone does not prove inbox delivery.

After a file-producing demo, disable its flow and wait for its runs to settle before deleting the owned flow. Flow deletion does not immediately remove generated files or native run logs. A project user with flow-write permission can explicitly delete an exact generated step-file ID through DELETE /api/v1/files/:fileId?projectId=<project-id>; this is not a live-run safety guard and can invalidate references to that file. A successful delete response is not independent physical-absence proof. Native run logs keep their normal retention policy.

41.3 Demo Flows

41.3.1 Demo 1: Create your first flow (5 minutes)

Goal: Search the knowledge base and display the answer.

Open Automations and choose Start from scratch or Create New > New Flow.
Add a Manual Trigger and the ask_nous_knowledge action.
Set the question to: “What is our remote work policy?”
Test the step and inspect the answer and its citations against the actual indexed policy that the runner can access.
Review the draft and publish it when ready.
For a published manual-trigger flow, choose Run Flow and inspect the actual run in Runs.

What this demonstrates: configuring a knowledge action and inspecting its answer and citations. Knowledge search uses indexed documents accessible to the flow runner.

41.3.2 Demo 2: Create a flow with AI (3 minutes)

Goal: Create a draft flow graph from a natural-language description.

Open the Automations home page and choose Create with AI.
Choose Workspace default or a currently visible explicit CHAT model.
Enter: “Every day at 9 AM in the intended Workspace timezone, search the knowledge base for recent updates and email a summary to the flow runner.”
Review the generated draft graph and correct its trigger, actions, mappings, and recipient.
Test the steps with the prepared Workspace data, then publish only after review.
Inspect the actual run and verify receipt in the runner’s mailbox.

What this demonstrates: AI-assisted draft creation and review, with schedule, knowledge, and email steps. Review and test the generated draft before publishing, using the intended Workspace timezone, accessible content, a configured model, and a readable mailbox.

41.3.3 Demo 3: Set up an approval workflow (5 minutes)

Goal: Use AI to review content before publishing.

Open Automations and create a manual-trigger flow.
Add Review with AI (llm_approval); enter the review rules in Review instruction and the material being evaluated in Review target.
Set Confidence threshold (confidenceThreshold) to 0.8 for this example; the action default is 0.75.
Add a Router with explicit branches for APPROVED, REJECTED, and NEEDS_HUMAN_REVIEW.
Route NEEDS_HUMAN_REVIEW through request_human_approval, configured with active Portal Workspace Approvers and a Decision deadline. Route its decision (APPROVED or REJECTED) explicitly too; rejection does not automatically stop later steps.
Put any notification email only on the intended branch, configure its recipients, and verify actual delivery separately.
Test the branches, review the draft, then publish and inspect the actual run.

What this demonstrates: explicit routing for AI review and human approval outcomes; the example value 0.8 is not the action default.

41.3.4 Demo 4: Run a research agent (5 minutes)

Goal: Use a Nous agent to research a topic and summarize results.

Open Automations and create a manual-trigger flow.
Add start_agent_run, select the enabled agent available to the Workspace, and enter: “Research the top 3 competitors in enterprise AI platforms.”
Map its returned agent_service_run_id to Get agent run status, selecting the same Agent.
Check status until it is terminal: completed, failed, or cancelled. A configured Agent Run Completed polling watcher can also signal a terminal state for its selected agent run.
Only on completed, add Get agent run artifacts with the same agent and service-run handle, then email the artifact output if that is the intended path. Handle failed or cancelled separately; do not request or email completed-run artifacts before terminal completion.
Review and publish the flow, then inspect its actual run.

What this demonstrates: tracking an asynchronous agent run by its service-run handle, retrieving artifacts after completed, and handling failed or cancelled outcomes separately.

41.3.5 Demo 5: Batch knowledge search (3 minutes)

Goal: Search multiple queries in one step.

Open Automations and choose Start from scratch or Create New > New Flow.
Add a Manual Trigger and batch_search_knowledge.
Supply the actual query array: ["current sprint goals", "open customer issues", "recent deployment notes"]; confirm the indexed corpus is accessible to the flow runner.
Test the step and inspect the result for each query.
Add ask_workspace_model to summarize the results, using Workspace default or a visible explicit CHAT model.
Review and publish the draft, then inspect the actual run.

What this demonstrates: a multi-query knowledge action and a model summary, subject to accessible indexed content and current model configuration.

41.4 Template Gallery Tour

The gallery contains 43 domain templates and 8 starter templates (51 distinct templates); domain-template category tags can overlap. From the Automations home page, choose Use Templates or open All templates. Search by template name or description, browse the category carousel, preview a template, and choose Use Template to create a draft from it.

41.5 Troubleshooting

41.5.1 Flow does not start

Confirm that the trigger settings are complete.
For schedules, verify the configured timezone and time.
For webhooks, use the Live/Test URL shown in trigger settings and verify the configured authentication method, header name, and secret/algorithm/encoding as applicable. HMAC signs the raw request body; a timestamp header is not required by this trigger.
Open Runs in the builder header and inspect the actual run.

41.5.2 Knowledge search returns no results

Confirm the queried content is indexed and accessible to the user who runs the flow.
Check the actual query and, if using a model action, the visible Workspace model/default and its provider.
Try a more specific query and inspect the action output.

41.5.3 Email not sent

Confirm Nous SMTP has SMTP_SERVER, SMTP_USER, and SMTP_PASS configured.
Check that RUN_USER or the selected active Portal Workspace members are the intended recipients.
Inspect the action result and any refused recipients, then verify actual receipt in a mailbox you can read.

41.5.4 AI model returns an error

Confirm that a currently visible CHAT model and Workspace default are configured through platform model governance; do not substitute an arbitrary LiteLLM alias.
For model failures, check that the selected model is visible, is available to the Workspace, and that its configured provider is reachable.