Nodes

The node catalog has 36 node types across the palette's three tabs: Triggers, Actions (including design and AI actions), and Rules (logic, timing, and flow control). Every node is fully configurable and validated the moment you place it. Some action nodes already run for real; a few are placed in the catalog ahead of their executor and honestly log a "not wired yet" step instead of pretending to succeed, see the When run column below.

Quick overview

1. Open the palette tab that matches what you need: Triggers, Actions, or Rules.
2. Drag the node onto the canvas.
3. Configure its fields in the inspector.
4. Check the tables below before depending on an action node's real-world effect.

Detailed reference

Triggers

Exactly one trigger node starts a graph. See Triggers for how each one actually fires.

Node	What starts a run
Manual start	You, from the builder's Test button
Scheduled	An interval, daily, or weekly cadence
Incoming webhook	A call to the automation's own URL
Design created	A new design is created
Design updated	A design is saved
Design shared	A design is shared or published
Design downloaded	A design is downloaded
Part tagged	A tag is added to a part, optionally filtered to one tag
Brand applied	A brand kit is applied to a design
Asset uploaded	A file is added to the media library
AI generation done	An AI generation finishes
New work in folder	A project is added to a chosen folder

Design actions

Node	What it does	Fields	When run
Pick a part	Choose a project, then a part inside it (page, frame, or slide); later steps act on it	Part (opens the part picker)	Runs for real
Set status / folder	Change the design's status and/or move it to a folder	Status, Folder	Runs for real
Publish a part	Publish the selected part as a community template	none	Not wired yet
Duplicate a design	Create a copy of the selected design	none	Not wired yet
Generate a cover	Generate a cover or thumbnail for the selected part	none	Not wired yet

AI actions

Runs through your own AI provider key, the same one used elsewhere in the app; see Bring your own AI key.

Node	What it does	Fields	When run
Generate copy	Writes text with an LLM	AI settings (opened from the node)	Runs for real with any connected AI key; otherwise it logs a skipped step
Generate an image	Text to image	AI settings (opened from the node)	Runs for real with an OpenAI-compatible key; any other provider, or no key, logs a skipped step
Generate a video	Text to video	AI settings (opened from the node)	Always logs a skipped step today; video is not connected to a provider yet, even with a key configured
Run an AI skill	Runs an AI Studio skill	AI settings (opened from the node)	Same as Generate an image for an image-producing skill; a video-producing skill always logs a skipped step

Notify actions

Node	What it does	Fields	When run
In-app notification	Creates a notification in your workspace	Message	Runs for real
Send webhook	Sends a POST request to a URL	URL	Runs for real
Slack / Discord	Posts a message via an incoming webhook	Webhook URL, Message	Runs for real
Write an audit entry	Adds a line to the audit log	none	Runs for real
Send email	Sends an email	To, Subject, Body	Runs for real through your workspace's configured SMTP connection; without one it logs a skipped step
Add to calendar	Adds an event to the workspace calendar	Title	Runs for real; it lands in your Portal Calendar's activity feed

Rules and logic

Every node here is handled by the core engine directly, so all of them run for real.

Node	What it does	Fields
Condition (yes/no)	Splits the flow into two branches based on a condition	Condition
Filter	Stops the flow if a condition is not met	Condition
Delay	Waits before continuing	Amount, Unit (minute, hour, day)
Wait until a date	Waits until a specific date and time	Date
Set a variable	Writes a value into the run's context for later steps	Key, Value
Expression / template	Builds a value from earlier outputs	Template
HTTP request	Calls a URL and stores the response	URL, Method, Body
No-op	Does nothing; a pass-through step	none
Exit	Ends the automation	none

Templates and conditions

Most text and textarea fields, the Expression / template node, and several notify fields accept double-brace placeholders, written as {{ context.someKey }}, that pull from whatever earlier nodes wrote into the run, for example the part you picked or a block of AI-generated text.

Condition (yes/no) and Filter build a structured rule instead: pick a field, a comparison (equals, contains, starts with, greater than, is empty, and more, depending on the field's data type), and a value. Either side of the rule can reference the run's context the same way, for example comparing {{ context.status }} against a fixed value like approved. An empty rule always passes, which is why a brand-new Condition or Filter node lets everything through until you configure it.

How to use it

Walkthrough: configure an HTTP request step

1. Drag HTTP request onto the canvas from the Rules tab and connect it after whatever node produces the data you need to send.
2. Set Method (GET, POST, PUT, PATCH, or DELETE) and URL; the URL field accepts {{ context.x }} just like any text field.
3. Pick Auth: None, Bearer token, Basic (user:pass), or a custom header, and fill in the matching value field that appears.
4. For a body-carrying method, pick a Body type (JSON, form, or raw text) and write the Body, again with placeholders where you need them.
5. Leave Response variable as the default __http, or rename it, then reference the result downstream, for example {{ context.__http.status }} or a value nested inside {{ context.__http.body }}.

Walkthrough: notify a Slack or Discord channel

1. In the destination app, create an incoming webhook for the channel you want to post to, and copy its URL.
2. Drag Slack / Discord onto the canvas (Actions > Notification) and paste that URL into Webhook URL.
3. Write the Message, using {{ context.x }} to include anything earlier nodes produced.
4. Optionally set Username and Icon emoji so automated posts are easy to spot in a busy channel.
5. Test the automation once; a failed post shows up as an error step with the HTTP status attached, not a silent no-op.

Common tasks

• Fire every weekday morning. On a Scheduled trigger, set Frequency to Cron, the expression to 0 9 * * 1-5, and a timezone like Europe/Istanbul. Cron mode keeps a catch-up pointer, so a missed minute (a deploy, a cold start) still fires once it's caught, rather than being silently lost.
• Only accept signed webhook calls. Fill in the Incoming webhook trigger's HMAC secret; the caller must then send an X-Signature: sha256=... header computed over the raw body, or the call is rejected with a 401 before anything runs.
• Move a part to review after approval. Chain Pick a part into Set status / folder, setting Status to "İncelemede" (In review); it calls the same update path the editor's own status control uses.
• Draft a caption or summary. A Generate copy node's prompt can reference earlier context directly, for example Summarize this in one sentence: {{ context.__aiText }} chained after another AI step.
• Call an external API and act on the response. A HTTP request node (Rules tab) can set Bearer/Basic/custom-header auth, write its response into a variable (default __http), and a Filter node right after it can gate on that response, for example only continuing when the call succeeded.
• Sign an outgoing webhook. The Webhook gönder (Send webhook) action's Secret field, if filled in, HMAC-SHA256-signs the request body and sends it in the header named in Signature header (default X-Signature), so the receiving side can verify the call actually came from your automation.
• Combine several context values into one string. Use Expression / template rather than several Set a variable nodes, for example {{ context.name }} <{{ context.email }}> written once into its Template field, then reference the result downstream as {{ context.__expr }}.
• Link a notification back to the work it's about. In-app notification's Href field accepts a path like /works/<id>, so clicking the notification in the workspace takes your team straight to the affected project.
• Stop a run early without it counting as a failure. Chain a Filter node with a rule that's false for the cases you want to drop; a filtered-out run shows as Exited in Runs, not Failed, and nothing after the filter runs.

Troubleshooting

• A node's step shows skipped in Activity. That's either an intentional filter (a Filter node whose condition failed), a node whose executor genuinely is not wired yet (see the "When run" columns above), or an action that has nothing to act on yet (email with no SMTP connection, AI with no matching key). None of these are bugs; the run still continues to whatever comes after.
• An action node keeps failing on the same step. Open its inspector's Settings tab and set a Retry count and wait, or change On error to Continue so the rest of the graph still runs; see Building a workflow.
• My condition never seems to pass (or never seems to fail). Check that the field it reads actually resolves to something: a typo in a {{ context.x }} path, or an upstream node that was itself skipped, both leave the value empty, and most comparisons other than "is empty" fail against an empty value.
• A run never started at all. That's a trigger-level question, not a node one; see Triggers for debounce, quiet hours, and Active-status gotchas.
• Set status / folder logs "önce bir parça seç" (pick a part first) and skips. This node acts on whatever part a Pick a part node chose earlier in the same run. Without one before it in the graph, there's nothing to act on, so it always skips with that message.
• "Publish a part," "Duplicate a design," or "Generate a cover" never seem to do anything. These three design actions are still ahead of their executor; they always log a skipped step and pass through, exactly like an AI or email node whose dependency isn't configured. Nothing you configure on them changes that today.
• A Slack post or an outgoing webhook silently didn't arrive. Check its entry in Recent step logs first. A bad or expired incoming webhook URL, or a target that returned a non-2xx status, both show as an error step with the response status in the message, not a hidden failure.

Tips

Skipped is not broken

A node marked "not wired yet" is not a bug. The run still passes through it, logs an honest "skipped" step, and continues to the next node, so the rest of your graph still works while you wait for that node's executor.

Combine condition and filter

Use Condition when you need two different paths (yes and no); use Filter when you just want to stop a run that does not qualify.

Related

• Building a workflow
• Triggers
• Running and monitoring
• Bring your own AI key