Examples

Each example is a graph shape assembled from nodes that are documented in this section and reachable in the 1.1.1 editor. They are illustrative patterns, not exported graphs: read them for why each node is where it is, then build the graph in your own installation and test it there.

Example 1 — RAG answer with a bounded agent

Webhook Trigger → SDP Action (ticket_read) → AI Agent (max 6 iterations) ⇠ Knowledge Vault (RAG)
                                                                      → Return

Step	Why it exists
Webhook Trigger	ServiceDesk Plus posts the ticket; the payload is the only input
SDP Action ticket_read	The agent must not guess ticket content; the read is explicit and auditable
Knowledge Vault (RAG) on the tools inlet	Gives the agent a search capability, not a fixed query
AI Agent, 6 iterations	Enough to search, re-search with better terms, and answer; bounded so a bad search cannot loop
Return	Sets the workflow result shape the caller reads

Why not a fixed rag_search + llm_call? Because the first query is often wrong. The agent can refine it — and the iteration cap keeps that freedom cheap.

Example 2 — Technician briefing

Webhook Trigger → SDP Action (ticket_read, full context) → AI Agent → SDP Action (ticket_add_note) → Return

Step	Why it exists
ticket_read with full context	The briefing needs conversation, worklogs, tasks and resolution, not just the subject
AI Agent	The summary shape depends on the ticket; a fixed prompt template truncates long tickets
ticket_add_note	The only write — one note per run, visible to the technician
Return	Reports what was written

The write is deliberately last and singular: if the agent produced nothing useful, the run fails before the note is created.

One note per run is not the same as exactly one note per ticket. The tool has no deduplication of its own, so a delivery that arrives twice — a ServiceDesk Plus retry without an Idempotency-Key, a manual re-run of the same trigger — writes a second note. If the trigger can retry, send Idempotency-Key; see API reference.

Example 3 — Incident escalation

Webhook Trigger → SDP Action (ticket_read) → AI Agent (classify severity)
                    ├─ True  → SDP Action (ticket_task_add, urgent task) → SDP Action (ticket_add_note)
                    └─ False → SDP Action (ticket_add_note, monitoring)

Step	Why it exists
AI Agent (classify)	Severity is a judgement over free text; it returns structured JSON the branch can read
IF Condition	Turns the judgement into two explicit, reviewable paths
Task + note on the true branch	Escalation needs an owner action, not only a note
Note-only false branch	Keeps the audit trail without waking anyone

The branch is the safety feature: the model classifies, the graph decides. If the classifier is wrong, the wrong branch runs — but the branch is visible in the run, so the mistake is obvious.

Patterns worth reusing

• Read before you reason. An explicit ticket_read before an agent makes the input auditable and stops the model inventing fields.
• Provider node → tools inlet, action node → main flow. Mixing them is the most common structural error.
• Bound every loop. Iterations for agents, maxIterations for loops.
• One write per branch. Several writes in sequence multiply the surface you cannot undo.
• Return the shape the caller expects. A workflow that ends without Return leaves the caller guessing.
• Capability, not instruction. Give the agent a search tool rather than a prompt that says “search the knowledge base”.

Related topics

Workflow designer · Node reference · AI agent nodes · Testing and debugging