--- title: "Workflow Setup & Examples" description: "Practical Norcaster workflow setup guide with supported node chains and use-case examples." canonical: https://www.norcaster.com/docs/workflow-examples --- Workflow recipes # Workflow setup and use-case examples These examples use workflow behavior that exists in Norcaster today: MCP input, retrieval, redaction, provider-backed model and agent calls, executable functions, routing, approvals, retries, fallbacks, and audit traces. ## Basic setup flow 1. Create provider-backed deployments for every model or agent node you plan to use. 2. Create a workflow and start with a single input node that matches your app request body. 3. Add data nodes first: mcp\_input for external systems, retrieval for knowledge bases, or tool\_call for HTTP tools. 4. Add privacy and control nodes before the model: redact\_text, policy\_check, condition, router, or approval. 5. Set each model or agent prompt\_field to a field that exists at that point in the run. 6. Run a test payload and inspect node outputs before connecting production traffic. ## Supported node cheat sheet ### mcp\_input Writes normalized MCP results to result\_field with text, raw, items\_count, and has\_text. ### redact\_text Edits configured string fields in place. Use dotted paths such as raw\_tickets.text. ### model Calls a provider-backed deployment. Use prompt\_field for deterministic model input. Output is screened by the deployment's output policy when one is configured. ### agent Runs a bounded native tool-calling loop with configured HTTP/webhook/internal functions. ### function Executes a deterministic HTTP, webhook, or internal function and returns audit fields. ### retrieval Returns retrieval.candidates from a knowledge base. ### answer\_with\_citations Formats retrieved evidence into final\_answer with citation metadata. ### tool\_call Calls HTTP, webhook, or internal tools. ### condition/router Routes to labeled outgoing edges based on payload fields. ### approval Pauses the run for human review before continuing. ## Use-case recipes ### DPA-safe ticket analysis Summarize support ticket trends without sending customer names, emails, phone numbers, or Swedish identifiers to the model. input → mcp\_input → redact\_text → model → output ``` { "mcp_input": { "server_url": "https://tickets.internal/mcp/sse", "transport": "sse", "tool_name": "search_tickets", "result_field": "raw_tickets", "tool_arguments": { "query": "{question}", "limit": 20 } }, "redact_text": { "fields": ["raw_tickets.text"], "patterns": ["email", "phone_se", "personnummer_se", "orgnumber_se"], "extra_patterns": ["\\+\\d{1,3}[\\s-]?\\d(?:[\\d\\s()-]{6,}\\d)"], "replacement": "[REDACTED]" }, "model": { "deployment_id": "dep_claude_support", "prompt_field": "raw_tickets.text" } } ``` Inspect the run trace for MCP output, redaction\_summary, provider/model metadata, and model\_request.messages. ### CRM account briefing Look up account context from an MCP server, redact contact data, and generate a short account summary. input → mcp\_input → redact\_text → model → output ``` { "mcp_input": { "server_url": "https://crm.internal/mcp", "transport": "http", "tool_name": "lookup_accounts", "result_field": "crm_context", "tool_arguments": { "query": "{question}", "include_contacts": false, "limit": 10 } }, "redact_text": { "fields": ["crm_context.text"], "patterns": ["email", "phone_se"], "extra_patterns": ["\\+\\d{1,3}[\\s-]?\\d(?:[\\d\\s()-]{6,}\\d)"] }, "model": { "deployment_id": "dep_account_summary", "prompt_field": "crm_context.text" } } ``` Use a stable result\_field so the redaction and model nodes always read the same normalized MCP text. ### Knowledge lookup with citations Search an uploaded knowledge base and return cited evidence for a customer or internal answer flow. input → retrieval → rerank → answer\_with\_citations → output ``` { "retrieval": { "knowledge_base_id": "kb_product_docs", "query_template": "{question}", "top_k": 8, "min_score": 0.2 }, "rerank": { "top_n": 5, "threshold": 0.2 }, "answer_with_citations": { "question_field": "question", "strict_mode": true } } ``` This workflow returns grounded citation objects from retrieved chunks. For full generated RAG answers, use the RAG API or add a supported prompt-building step before a model node. ### Human approval before an external action Pause high-risk actions for manual review before calling a webhook or internal HTTP tool. input → condition → approval → tool\_call → output ``` { "condition": { "field": "risk_level", "operator": "in", "value": ["high", "critical"] }, "approval": { "payload": { "reason": "High-risk workflow action requires review" } }, "tool_call": { "execution_type": "http", "method": "POST", "endpoint": "https://ops.internal/actions", "body_field": "tool_input", "timeout_ms": 10000 } } ``` The approval node creates a waiting\_approval run state. The HTTP tool only runs after the workflow resumes. ### Policy gate before model inference Run the deployment's runtime policy on the incoming payload before any model call, and record the decision. input → policy\_check → model → output ``` { "policy_check": { "surface": "input", "mode": "enforce", "prompt_field": "question" }, "model": { "deployment_id": "dep_safe_chat", "prompt_field": "question" } } ``` The policy\_check node evaluates the deployment's effective policy on the payload and records an enforcement event on the run. A block stops the workflow (mode: enforce) or is recorded and passed through (mode: warn); a redaction is written back as redacted\_text. Placed after a model node it screens the generated output instead (surface auto-detects). The model node still runs its own input pass before provider inference. ### Provider fallback branch Try one provider-backed model first and fall back to another node if the first node fails. input → model\_primary → output, with fallback\_node\_id: model\_backup ``` { "model_primary": { "deployment_id": "dep_primary_model", "prompt_field": "question" }, "model_backup": { "deployment_id": "dep_backup_model", "prompt_field": "question" }, "node_options": { "fallback_node_id": "model_backup", "retry_policy": { "max_attempts": 2, "backoff_type": "exponential", "backoff_ms": 250 } } } ``` fallback\_node\_id and retry\_policy are supported workflow node properties. Use a provider-backed deployment for each model node. ### Native tool-calling account agent Let a provider-backed model decide when to call an approved account lookup function, then produce a final answer. input → agent → output ``` { "agent": { "deployment_id": "dep_reasoning_model", "prompt_field": "question", "max_iterations": 4, "tools": [ { "name": "lookup_account", "description": "Fetch account context by account ID", "input_schema": { "type": "object", "properties": { "account_id": { "type": "string" } }, "required": ["account_id"] }, "function": { "execution_type": "http", "method": "POST", "endpoint": "https://crm.internal/account", "body_template": { "account_id": "{account_id}" } } } ] } } ``` The run trace records agent\_steps, native tool calls, function requests/responses, token usage, and the final agent\_output. ## Production checklist - Every model node uses a real provider-backed deployment. - Every prompt\_field points to a field that exists after upstream nodes finish. - PII redaction runs before external provider inference. - Large external payloads are reduced before model inference to control cost and latency. - Approval and tool\_call nodes are tested with non-production endpoints before real side effects. - Audit traces show node inputs, outputs, redaction counts, model request payloads, errors, and retries. - Use the [observability guide](https://www.norcaster.com/docs/observability) to debug failed runs, weak citations, missing MCP data, and slow agent/tool calls. - For schema validation, guardrails, and budgets, use the [boundary enforcement guide](https://www.norcaster.com/docs/boundary-enforcement).