Flow+ Node Reference

Workroomly EditorialOctober 28, 2026

Find the node you need to start an automation, make a decision or perform the next step. This reference covers the 301 nodes in the current catalogue: 98 triggers, 61 conditions and 142 actions. It is a lookup guide; you do not need to read every entry before building your first workflow.

Start with the result you want

Suppose you want your team to hear about a new high-priority support ticket. Think of the workflow in three parts:

Start: use When a ticket is created in Desk.
Decide: use If ticket priority is... to check for high priority.
Act: connect Post message in Chat to the matching path, with your team channel as the destination.

A trigger watches for the starting event. A condition chooses the next path; it does not change the ticket itself. An action performs a step on the connected path. If you only want to try the logic with a sample ticket, start with Manual trigger before enabling event-driven execution.

Find and configure a node

Open your workflow in Flow+ and add a node.
Choose its type: trigger, condition or action.
Select the provider or module, then the exact node name shown in this reference.
Complete the node's fields. Select the record, status, owner or destination where the form offers a picker. Where an ID is required, use the ID supplied by the relevant record or configuration screen; do not substitute its name.
Connect the next step to the correct output. For a yes/no condition, decide what should happen on both the matching and nonmatching paths. Switch / Match can route several cases plus a default path.
Save, reopen and check the configuration. Run a controlled test with sample data, inspect the run result, and check the actual record or message in its module.

The descriptions below explain the purpose of each catalogue entry. Exact fields, options and available integrations depend on your workroom. A node appearing in the catalogue is not a guarantee that a service is connected or that a workflow is activated.

Choose the right kind of operation

Create adds a record; Update changes an existing one. Use a known existing record when updating.
Request submits work for a process to handle. It does not mean approval, completion or posting has happened.
Set status or stage changes a field. A Transition follows a configured process step; use it when that process is required.
Await waits for a decision or result. Inspect reads the available state or outcome. Neither is the same as starting a new run.
A report or agent result may be queued. Check the resulting export or run before treating the work as complete.
Sending messages, email or invitations can reach real people. Use your intended destination and verify recipients before enabling a workflow.

Terms used in the list

SLA: a service-level agreement, such as a target response or resolution time for a support ticket.
OKR and KR: objectives and key results; a key result is a measurable outcome used to track progress.
Act: an AI activity configured in CoBrain, with its own lifecycle and runs. An Act's state is different from the outcome of one run.
API and webhook: an API lets systems exchange requests and data; a webhook is an incoming request that can start a workflow.
Custody: who currently holds or is responsible for an asset.
Fulfilment: the operational process of supplying an order, separate from collecting its payment.

Browse the catalogue

The reference is arranged by Triggers, Conditions and Actions, then by the provider names used in Flow+. Use your browser's Find command to jump to a module or an exact node name. Each entry explains what the node does and when you would choose it.

Triggers (98)

Approvals

1. When a step awaits decision

Starts the workflow when an approval step is waiting for a decision.

Typical use: Prompt the responsible approver or begin a waiting-stage follow-up.

A waiting step is not an approval decision or completion of the whole request.

2. When approval is cancelled

Starts the workflow when an approval is cancelled.

Typical use: Stop or revise follow-up work tied to an approval that is no longer proceeding.

3. When approval is decided

Starts the workflow when an approval decision is recorded.

Typical use: Route the next work according to the decision outcome.

Check the outcome before proceeding; a decision does not necessarily mean approval.

4. When approval is requested

Starts the workflow when an approval is requested.

Typical use: Begin intake, tracking, or reviewer notification for a new approval request.

A request is not yet an approval outcome.

Assets

5. When an asset assignment progresses

Starts the workflow when an asset assignment advances in its process.

Typical use: Coordinate the next handoff as equipment is being assigned.

Progress can be an intermediate step; do not treat every event as a completed assignment.

6. When an asset return progresses

Starts the workflow when an asset return advances in its process.

Typical use: Coordinate collection, inspection, or other follow-up during an equipment return.

Progress can be an intermediate step; do not assume the asset has already been received.

7. When an asset transfer is requested

Starts the workflow when an asset transfer is requested.

Typical use: Begin review or coordination for moving an asset between holders or locations.

The request does not itself confirm that the transfer has happened.

BI

8. When report export completes

Starts the workflow when a report export completes.

Typical use: Begin distribution or other follow-up after an export is ready.

9. When report export fails

Starts the workflow when a report export fails.

Typical use: Notify the report owner or initiate investigation of an unsuccessful export.

Billing

10. When payment fails

Starts the workflow when a billing payment fails.

Typical use: Begin a payment-exception follow-up for the relevant customer or account.

Payment recovery or a new charge requires a separate, appropriate action.

11. When subscription status changes

Starts the workflow when a subscription's status changes.

Typical use: Keep customer follow-up or internal records aligned with a subscription change.

Check the new status; this trigger is not limited to cancellations or renewals.

Boards

12. When a project is created

Starts the workflow when a Boards project is created.

Typical use: Begin project kickoff, ownership checks, or setup tasks.

13. When a project status changes

Starts the workflow when a Boards project's status changes.

Typical use: Coordinate the next phase of work as a project changes state.

Check the destination status before applying phase-specific actions.

14. When a sprint is created

Starts the workflow when a sprint is created.

Typical use: Begin sprint preparation, planning reminders, or coordination.

15. When a sprint status changes

Starts the workflow when a sprint's status changes.

Typical use: React to sprint-state changes with the appropriate planning or review follow-up.

Check the destination status rather than assuming the sprint has finished.

16. When a task is created

Starts the workflow when a Boards task is created.

Typical use: Begin triage, assignment review, or task-creation notifications.

17. When an epic is created

Starts the workflow when an epic is created.

Typical use: Start coordination for a new larger body of work.

18. When an epic status changes

Starts the workflow when an epic's status changes.

Typical use: Coordinate handoffs or review when an epic moves to a different state.

Check the destination status before treating the epic as complete.

19. When task status changes

Starts the workflow when a Boards task's status changes.

Typical use: Route handoffs, reminders, or completion follow-up based on the task's new state.

Check the destination status; not every status change means completion.

CRM

20. When a contact is created

Starts the workflow when a CRM contact is created.

Typical use: Begin new-contact review, enrichment, or relationship follow-up.

21. When a contact owner is assigned

Starts the workflow when an owner is assigned to a CRM contact.

Typical use: Begin the contact owner's handoff or follow-up tasks.

22. When a deal is closed lost

Starts the workflow when a deal is marked closed lost.

Typical use: Begin loss review, reason capture, or appropriate future follow-up.

23. When a deal is closed won

Starts the workflow when a deal is marked closed won.

Typical use: Begin the sales-to-delivery handoff or customer-start process.

A won deal does not by itself confirm payment, fulfilment, or delivery.

24. When a deal is created

Starts the workflow when a CRM deal is created.

Typical use: Begin deal qualification, ownership checks, or pipeline coordination.

25. When a deal owner is assigned

Starts the workflow when an owner is assigned to a deal.

Typical use: Initiate a deal handoff and the new owner's next steps.

26. When a deal stage changes

Starts the workflow when a deal moves between pipeline stages.

Typical use: Coordinate stage-specific work such as review or preparation for the next sales step.

A pipeline-stage change is distinct from a deal-status change.

27. When a deal status changes

Starts the workflow when a deal's status changes.

Typical use: React to the deal's new business state with the appropriate follow-up.

Check the new status; use the specific closed-won or closed-lost trigger when that is the event you need.

28. When a lead is converted

Starts the workflow when a lead is converted.

Typical use: Begin the next relationship or sales-process handoff after lead conversion.

Do not assume which related records were created without checking the conversion result.

29. When a lead is created

Starts the workflow when a CRM lead is created.

Typical use: Begin lead intake, qualification, or follow-up coordination.

30. When a lead owner is assigned

Starts the workflow when an owner is assigned to a lead.

Typical use: Begin the assigned owner's outreach or qualification handoff.

31. When a lead stage changes

Starts the workflow when a lead moves between pipeline stages.

Typical use: Coordinate stage-specific qualification or nurturing work.

A stage change is distinct from a lead-status change.

32. When a lead status changes

Starts the workflow when a lead's status changes.

Typical use: Adjust follow-up to the lead's new business state.

Check the new status instead of assuming the lead is qualified or converted.

33. When an account is created

Starts the workflow when a CRM account is created.

Typical use: Begin account setup, ownership review, or account-planning work.

34. When an account owner is assigned

Starts the workflow when an owner is assigned to a CRM account.

Typical use: Coordinate the account handoff and the new owner's next steps.

35. When an activity is logged

Starts the workflow when a CRM activity is logged.

Typical use: Create follow-up after a recorded customer interaction or other CRM activity.

Check the activity type and context before selecting follow-up work.

Chat

36. When a message is posted

Starts the workflow when a chat message is posted.

Typical use: Begin a message-driven intake or follow-up process.

Define the relevant message scope carefully to avoid treating every conversation as a request.

Cobrain

37. Act activation decision

Starts the workflow when Cobrain records an activation decision for an Act.

Typical use: Coordinate review or follow-up around whether an Act should be activated.

A decision is not necessarily an approval and does not mean the Act has run.

38. Act lifecycle changed

Starts the workflow when an Act's lifecycle state changes in Cobrain.

Typical use: Keep oversight or coordination in step with an Act's state changes.

Check the new state; a lifecycle change is not the same as a completed run.

39. Act run finished

Starts the workflow when an Act run finishes in Cobrain.

Typical use: Inspect the outcome and coordinate any next step after the run ends.

Finished does not necessarily mean successful; check the outcome before acting on it.

40. Built-in agent activation decision

Starts the workflow when Cobrain records an activation decision for a built-in agent.

Typical use: Coordinate review or follow-up around activating a built-in agent.

A decision is not necessarily approval and does not mean the agent has run.

41. Built-in agent lifecycle changed

Starts the workflow when a built-in agent's lifecycle state changes in Cobrain.

Typical use: Keep oversight or dependent work aligned with the agent's state.

Check the new state; a lifecycle change is distinct from a run finishing.

42. Built-in agent run finished

Starts the workflow when a built-in agent run finishes in Cobrain.

Typical use: Review the run outcome or begin an appropriate follow-on process.

Finished does not necessarily mean successful; inspect the outcome first.

Desk

43. When SLA is breached

Starts the workflow when Desk reports a service-level agreement (SLA) breach.

Typical use: Begin escalation or service-recovery follow-up after an SLA target is missed.

44. When SLA warning is triggered

Starts the workflow when Desk raises an SLA warning.

Typical use: Begin preventive follow-up before a possible service-level breach.

A warning is distinct from a confirmed breach.

45. When a comment is added

Starts the workflow when a comment is added in Desk.

Typical use: Begin follow-up prompted by a new ticket discussion entry.

46. When a ticket is assigned

Starts the workflow when a Desk ticket is assigned.

Typical use: Begin the assignee's ownership handoff or response process.

Use the separate reassignment trigger when the intended event is a change of assignee.

47. When a ticket is closed

Starts the workflow when a Desk ticket is closed.

Typical use: Begin closure review, reporting, or customer follow-up.

48. When a ticket is created

Starts the workflow when a Desk ticket is created.

Typical use: Begin support intake, triage, or acknowledgement.

49. When a ticket is reassigned

Starts the workflow when a Desk ticket is reassigned.

Typical use: Coordinate the handoff to the new assignee.

50. When a ticket is reopened

Starts the workflow when a Desk ticket is reopened.

Typical use: Restart investigation or follow-up for an issue requiring further attention.

51. When ticket priority changes

Starts the workflow when a Desk ticket's priority changes.

Typical use: Adjust escalation or response coordination to the new priority.

Check the new priority; a change can reduce urgency as well as increase it.

52. When ticket status changes

Starts the workflow when a Desk ticket's status changes.

Typical use: Coordinate work for the ticket's new state.

Use the more specific closure or reopening trigger when that is the only event needed.

External Events

53. When an external event arrives

Starts the workflow when an external event arrives.

Typical use: React to an event produced outside the native business-module triggers.

Confirm the supported event source and event data before choosing downstream actions.

Files

54. When a document is created

Starts the workflow when a document is created in Files.

Typical use: Begin document review, organization, or ownership follow-up.

55. When a document is updated

Starts the workflow when a document in Files is updated.

Typical use: Begin revision review or notify collaborators about a change.

Avoid a workflow that repeatedly updates the same document in response to its own changes.

56. When a file is uploaded

Starts the workflow when a file is uploaded.

Typical use: Begin file intake, review, or organization.

57. When a folder is created

Starts the workflow when a folder is created.

Typical use: Begin coordination or setup work for a new file-organizing location.

Finance

58. When an invoice becomes overdue

Starts the workflow when an invoice becomes overdue.

Typical use: Begin a receivables review or payment follow-up.

Check the current invoice and payment state before contacting the customer.

Goals

59. When KR progress updates

Starts the workflow when a key result's progress is updated.

Typical use: Refresh goal oversight or begin a progress-review follow-up.

A progress update is not necessarily improvement or completion.

60. When goal becomes at risk

Starts the workflow when a goal becomes at risk.

Typical use: Begin an intervention, owner check-in, or recovery-plan review.

Use the goal's recorded risk state rather than assuming a particular threshold calculation.

Inbox

61. When an email is received

Starts the workflow when an email is received in Inbox.

Typical use: Begin email-driven intake, review, or response coordination.

Select an appropriate scope so unrelated mail does not trigger business actions.

Inventory

62. When a sales fulfilment is confirmed

Starts the workflow when a sales fulfilment is confirmed.

Typical use: Coordinate the next operational handoff after fulfilment confirmation.

Confirmation is distinct from the separate ready-to-dispatch and ready-to-invoice events.

63. When an order is ready to dispatch

Starts the workflow when an order is marked ready to dispatch.

Typical use: Begin shipping coordination or a dispatch-readiness handoff.

Ready to dispatch does not mean dispatched or delivered.

64. When days of cover crosses a threshold

Starts the workflow when inventory days of cover crosses a threshold.

Typical use: Begin stock-coverage review or replenishment coordination.

Confirm the threshold and crossing direction; the label alone does not define either.

65. When fulfilment is ready to invoice

Starts the workflow when fulfilment is marked ready to invoice.

Typical use: Begin the finance handoff for invoicing fulfilled work or goods.

Readiness does not mean an invoice has been created or sent.

66. When stock is placed on quality hold

Starts the workflow when stock is placed on quality hold.

Typical use: Begin quality review and coordination for affected stock.

The event reports the hold; it does not release stock or resolve the issue.

Meet

67. When a meeting is created

Starts the workflow when a meeting is created in Meet.

Typical use: Begin meeting preparation or coordination with the relevant team.

Creation is distinct from the meeting starting, ending, or being attended.

People

75. When a course is assigned

Starts the workflow when a course is assigned in People.

Typical use: Begin learner notification or training coordination.

An assignment is not course completion.

76. When a course is completed

Starts the workflow when a course is recorded as completed in People.

Typical use: Begin completion acknowledgement or the learner's next development step.

77. When a learning path is assigned

Starts the workflow when a learning path is assigned.

Typical use: Begin coordination for a person's structured learning plan.

A learning-path assignment is distinct from assigning an individual course.

78. When a learning path is completed

Starts the workflow when a learning path is recorded as completed.

Typical use: Begin acknowledgement or the next development-plan handoff.

Path completion is distinct from completion of just one course.

79. When employee is created

Starts the workflow when an employee record is created in People.

Typical use: Begin new-employee record checks or setup coordination.

Creating the record is distinct from the separate onboarding-start event.

80. When leave is approved

Starts the workflow when a leave request is approved.

Typical use: Coordinate coverage and other follow-up for approved absence.

81. When leave is rejected

Starts the workflow when a leave request is rejected.

Typical use: Begin appropriate notification or follow-up on the declined request.

82. When onboarding starts

Starts the workflow when onboarding begins.

Typical use: Coordinate the initial onboarding tasks and handoffs.

83. When training attendance is recorded

Starts the workflow when training attendance is recorded.

Typical use: Begin attendance-related follow-up or training administration.

Attendance alone does not necessarily mean a course or learning path is complete.

84. When training is scheduled

Starts the workflow when training is scheduled.

Typical use: Begin preparation, participant coordination, or reminders.

Scheduled training is not evidence of attendance or completion.

Procure

85. When a contract goes for approval

Starts the workflow when a procurement contract is sent for approval.

Typical use: Begin review coordination or approval tracking.

Being sent for approval does not mean the contract has been approved or signed.

86. When a purchase order is created

Starts the workflow when a purchase order is created.

Typical use: Begin purchase-order review or internal coordination.

Creation is distinct from submission of the purchase order.

87. When a purchase order is submitted

Starts the workflow when a purchase order is submitted.

Typical use: Begin follow-up tied to the purchase order's submission.

Submission alone does not confirm approval, supplier acceptance, or receipt of goods.

88. When a purchase request is approved

Starts the workflow when a purchase request is approved.

Typical use: Begin the next purchasing handoff after approval.

Approval of a request does not itself create a purchase order.

89. When a purchase request is submitted

Starts the workflow when a purchase request is submitted.

Typical use: Begin review, tracking, or purchasing-intake coordination.

A submitted request is not yet approved.

90. When goods are received/accepted

Starts the workflow when Procure records goods as received or accepted.

Typical use: Begin receipt-related checks, reconciliation, or the next purchasing handoff.

Confirm whether the event represents receipt or acceptance before assuming quality approval.

Produce

91. When a production order is completed

Starts the workflow when a production order is completed.

Typical use: Begin completion review or coordination with the next operational team.

Production completion does not by itself confirm shipment or customer delivery.

92. When a production order is created

Starts the workflow when a production order is created.

Typical use: Begin production planning, readiness checks, or team coordination.

93. When production is delayed

Starts the workflow when a production delay is reported.

Typical use: Begin schedule review, escalation, or coordination with affected teams.

The label does not specify how the delay is detected or measured.

System

94. Manual trigger

Starts the workflow when someone manually launches a run.

Typical use: Offer an on-demand process that a person starts when ready, rather than waiting for a business event.

95. On schedule

Starts the workflow at the configured scheduled time, using the chosen date, time, and time zone.

Typical use: Run a time-based check or routine without a new business record having to change.

Check the time zone and schedule settings before activating the workflow.

96. Webhook trigger

Starts the workflow from an incoming HTTP request to its webhook entry point.

Typical use: Let another system initiate a Flow+ process through an HTTP integration.

Match the sender to the configured request methods, authentication, and response mode.

Transport

97. When a delivery fails

Starts the workflow when a delivery is recorded as failed.

Typical use: Begin exception handling, investigation, or customer follow-up.

A new delivery attempt requires a separate decision and action.

98. When a delivery is completed

Starts the workflow when a delivery is recorded as completed.

Typical use: Begin delivery confirmation follow-up or post-delivery coordination.

Conditions (61)

Approvals

1. Approval status is

Checks whether an approval has the selected status.

Typical use: Separate follow-up paths according to where an approval stands.

Checking a status does not approve, reject, or cancel the request.

2. Approval target type is

Checks the type of item that an approval concerns.

Typical use: Use different follow-up steps for different kinds of approval targets.

3. Decision was

Checks whether an approval decision matches the decision being tested.

Typical use: Choose the next path based on the decision already recorded.

This checks a decision; it does not make one.

Assets

4. Asset custody state is

Checks whether an asset has the selected custody state.

Typical use: Branch according to the asset’s custody situation before a handover or return step.

Custody state and financial state answer different questions; this does not transfer the asset.

5. Asset financial state is

Checks whether an asset has the selected financial state.

Typical use: Apply different follow-up paths according to the asset’s financial lifecycle.

This is a state check, not an accounting entry or a custody change.

6. Maintenance due within days

Checks whether asset maintenance is due within a specified number of days.

Typical use: Identify assets that need near-term maintenance follow-up.

Confirm how the editor treats already-overdue maintenance and the date boundary before using it for reminders.

Billing

7. Subscription status is

Checks whether a subscription has the selected status.

Typical use: Choose follow-up steps for different subscription states.

This does not change the subscription or collect a payment.

Boards

8. If epic status is…

Compares an epic’s current status with the selected status.

Typical use: Run the next steps only for epics at the relevant stage of work.

9. If project status is…

Checks whether a project has the selected status.

Typical use: Gate project-level follow-up on the project’s current state.

10. If sprint status is…

Checks whether a sprint has the selected status.

Typical use: Separate planning, active-work, or wrap-up paths according to the sprint state.

11. If task status is…

Compares a task’s current status with the selected status.

Typical use: Continue along the matching path when a task is at the required work stage.

CRM

12. If account health score matches…

Tests an account’s health score against a configured numeric comparison.

Typical use: Separate accounts for different attention or follow-up based on recorded health scores.

A missing score is not a measured health score; plan how incomplete account data should be handled.

13. If account owner is…

Checks whether an account is owned by the selected person.

Typical use: Apply owner-specific account follow-up without changing ownership.

14. If activity channel is…

Checks whether a CRM activity uses the selected channel.

Typical use: Handle different kinds of recorded customer interaction along different paths.

This checks the activity’s channel; it does not send a message through that channel.

15. If activity entity type is…

Checks the type of CRM record that an activity relates to.

Typical use: Distinguish activity follow-up by the kind of associated record, such as a deal.

16. If contact lifecycle status is…

Checks whether a contact’s lifecycle status matches the selected status.

Typical use: Tailor the next steps to the contact’s current relationship stage.

17. If contact owner is…

Checks whether a contact is owned by the selected person.

Typical use: Route contact follow-up according to existing ownership.

18. If deal amount matches…

Tests a deal’s amount against a configured numeric comparison.

Typical use: Use different paths for deals that meet your value criterion.

Choose the comparison deliberately; this check does not change the deal amount.

19. If deal owner is…

Checks whether a deal is owned by the selected person.

Typical use: Apply owner-specific deal follow-up without reassigning the deal.

20. If deal stage is…

Checks whether a deal is in the selected pipeline stage.

Typical use: Gate stage-specific sales work on the deal’s current pipeline position.

Stage and status are separate checks; select the one that represents your business rule.

21. If deal status is…

Checks whether a deal has the selected status.

Typical use: Choose follow-up paths according to the deal’s recorded status.

This does not move the deal to another stage or close it.

22. If lead has tag…

Checks whether a lead has the specified tag.

Typical use: Target a path to leads already marked with a relevant classification.

This checks an existing tag; it does not add or remove tags.

23. If lead owner is…

Checks whether a lead is owned by the selected person.

Typical use: Route lead follow-up based on the current owner.

24. If lead stage is…

Checks whether a lead is in the selected pipeline stage.

Typical use: Run stage-specific lead handling only when the lead is at that point in the process.

This checks the stage; it does not move or convert the lead.

25. If lead status is…

Checks whether a lead has the selected status.

Typical use: Branch according to the lead’s recorded qualification or working status.

Cobrain

26. Act run outcome

Checks the outcome of a Cobrain Act run against the outcome being tested.

Typical use: Choose follow-up steps based on how an Act run finished.

An outcome check does not start or retry the Act.

27. Act state

Checks whether a Cobrain Act is in the selected lifecycle state.

Typical use: Gate follow-up on the Act’s current state rather than the result of an individual run.

Act state and Act run outcome are different checks.

28. Built-in agent run outcome

Checks the outcome of a built-in agent run against the outcome being tested.

Typical use: Choose a follow-up path based on how that agent run finished.

This does not start or retry the agent.

29. Built-in agent state

Checks whether a built-in agent is in the selected state.

Typical use: Make a decision based on the agent’s state rather than an individual run result.

The condition does not activate, disable, or otherwise change the agent.

Control Flow

30. If / Else

Compares two configured values and selects the true or false path.

Typical use: Make a two-way decision using values available to the workflow.

Connect the paths you need; the condition itself performs no business action.

31. Switch / Match

Matches a value against configured cases and selects a case path or the default path.

Typical use: Choose among several outcomes instead of building a chain of two-way checks.

Provide a default path when unmatched values need handling.

Desk

32. If ticket SLA is breached...

Checks whether a ticket has breached its resolution deadline.

Typical use: Gate escalation follow-up on a breached ticket resolution target.

For an overdue response rather than resolution, use “If ticket response is overdue...”.

33. If ticket has an unread customer reply...

Checks whether a ticket has an unread customer reply.

Typical use: Separate tickets needing attention to a customer’s latest reply.

This does not send a response or mark a reply as read.

34. If ticket is assigned to...

Checks whether a ticket is assigned to the selected agent.

Typical use: Apply agent-specific follow-up or route work based on existing assignment.

This checks assignment; it does not assign the ticket.

35. If ticket priority is...

Checks whether a ticket has the selected priority.

Typical use: Apply a different follow-up path for tickets of a particular urgency.

36. If ticket response is overdue...

Checks whether a ticket’s response deadline has passed.

Typical use: Identify tickets needing overdue-response follow-up.

This is a response-time check, not the resolution-deadline check.

37. If ticket status is...

Checks whether a ticket has the selected status.

Typical use: Run the next steps only for tickets at the relevant stage of handling.

Choose a status from the appropriate Desk; the condition does not change it.

Files

38. If resource is shared

Checks whether a file resource is shared.

Typical use: Branch according to whether sharing is already in place.

Do not treat this alone as proof that a particular person has access; the label does not specify recipient or permission scope.

Finance

39. Expense request status is

Checks whether an expense request has the selected status.

Typical use: Choose follow-up steps appropriate to the request’s current state.

The condition does not approve or pay the expense.

40. Invoice amount threshold

Checks an invoice amount against a configured threshold.

Typical use: Separate invoices for different handling based on their amount.

Confirm the comparison direction and amount basis in the editor; the node label alone does not specify them.

41. Invoice status is

Checks whether an invoice has the selected status.

Typical use: Route invoice follow-up according to its current state.

This does not issue, settle, or cancel the invoice.

Goals

42. If KR progress ≥

Checks whether a key result’s recorded progress is greater than or equal to a threshold.

Typical use: Run milestone follow-up when a key result reaches a chosen progress level.

Use the progress scale shown by the node rather than assuming a displayed percentage uses the same units.

43. If OKR status is…

Checks whether the selected goal record has the specified OKR status.

Typical use: Choose a path according to the goal’s current status, rather than its numeric progress.

Inbox

44. If folder is…

Checks whether an email is associated with the specified folder.

Typical use: Apply different handling to mail in different folders.

The condition checks location; it does not move the email.

45. If from address matches

Tests an email’s sender address against the configured match.

Typical use: Route messages from relevant senders to a specific handling path.

Confirm the available matching rule; do not assume domain, wildcard, or regular-expression matching from the label.

46. If subject contains…

Checks whether an email subject contains the specified text.

Typical use: Separate messages by a recognizable subject phrase.

This checks the subject, not the email body or attachments.

Inventory

47. Fulfilment status is

Checks whether a fulfilment record has the selected status.

Typical use: Gate the next operational step on the fulfilment’s current state.

This does not confirm fulfilment, dispatch goods, or create an invoice.

Meet

48. If meeting has a recording

Checks whether a meeting has a recording.

Typical use: Choose a follow-up path that depends on a recording being available.

This does not start recording or grant access to the recording.

49. If meeting has a transcript

Checks whether a meeting has a transcript.

Typical use: Gate transcript-based follow-up on a transcript being available.

This does not generate a transcript.

People

56. Leave status is

Checks whether a leave request has the selected status.

Typical use: Route leave-related follow-up according to the request’s current state.

This does not approve, reject, or cancel leave.

Procure

57. Request procurement stage is

Checks whether a procurement request is at the selected stage.

Typical use: Gate procurement follow-up on the request reaching the relevant process stage.

This checks the stage; it does not advance the request.

58. Supplier lifecycle is

Checks whether a supplier has the selected lifecycle state.

Typical use: Choose supplier-related follow-up appropriate to the supplier’s current state.

This does not onboard, activate, or otherwise change the supplier.

Produce

59. Production order status is

Checks whether a production order has the selected status.

Typical use: Route production follow-up according to the order’s current state.

This does not start, complete, or update the production order.

System

60. Expression

Evaluates a configured comparison to produce a true or false result.

Typical use: Make a general-purpose decision from workflow values when a record-specific condition is not the right fit.

Use the comparison inputs offered by the editor; the label is not evidence of unrestricted code execution.

Transport

61. Delivery status is

Checks whether a delivery has the selected status.

Typical use: Choose operational or customer follow-up according to the delivery’s current state.

This does not dispatch, complete, or otherwise change the delivery.

Actions (142)

Approvals

1. Cancel approval request and record

Cancels the selected approval request using the node’s available cancellation settings.

Typical use: An outstanding approval should no longer proceed.

Check which approval instance and record are targeted; do not treat this as cancellation of every related business transaction.

2. Request approval

Submits a request into an approval process.

Typical use: Work should be reviewed before a later business action proceeds.

Requesting approval is not an approval decision; continue based on the recorded outcome.

Assets

3. Request asset assignment

Requests that an asset be assigned to a custodian.

Typical use: An employee or team needs an asset issued through the asset process.

This starts a request; it does not by itself establish completed custody.

4. Request asset return

Requests the return of an assigned asset.

Typical use: An asset needs to come back after a loan, role change, or offboarding.

Track the return process separately from the request being accepted.

5. Request asset transfer

Requests an asset transfer to a different destination or custodian.

Typical use: An asset needs to move between eligible owners or locations.

A transfer request is not proof that the asset has changed custody.

BI

6. Generate BI report

Queues generation of the selected BI report.

Typical use: A workflow should request a fresh report or export.

A queued job is not a finished report; check its completion and resulting artifact before distributing it.

Boards

7. Add board member

Adds a selected user to a board’s membership.

Typical use: Someone needs access to participate in the board.

Use an eligible user and consider the access granted by board membership.

8. Assign epic

Assigns responsibility for an epic.

Typical use: A larger body of work needs a clear owner or assignee.

9. Assign task

Assigns responsibility for a task.

Typical use: A task should be routed to the person who will handle it.

10. Create board

Creates a board for organizing work.

Typical use: A new team or workstream needs its own work board.

11. Create component

Creates a component within the selected project context.

Typical use: You need to group related work by a functional area or deliverable.

12. Create epic

Creates an epic in the selected board and project context.

Typical use: A substantial outcome should be tracked above individual tasks.

13. Create project

Creates a project on the selected board, using the supplied planning details.

Typical use: A new initiative needs a named project with its own dates and estimates.

14. Create sprint

Creates a sprint for a defined period of work.

Typical use: A team needs a new iteration in which to plan and deliver work.

15. Create task

Creates a task with the supplied title, project context, and supported details.

Typical use: An event or decision should produce a trackable work item.

16. Remove board member

Removes a selected user from a board’s membership.

Typical use: Someone no longer needs to participate in that board.

Removing board membership is not the same as removing the user from the workroom.

17. Set epic priority

Sets the selected epic’s priority.

Typical use: The relative urgency or importance of an epic has changed.

18. Set epic resolution

Sets the selected epic’s resolution value.

Typical use: You need to record how an epic was resolved.

Resolution is a distinct field; do not assume this also changes every related task or lifecycle status.

19. Set priority

Sets a task’s priority.

Typical use: A task needs to be promoted or lowered in the work queue.

This is the task-priority action; use Set epic priority for an epic.

20. Update board

Changes supported details of an existing board.

Typical use: A board’s information needs to be revised without creating a new board.

21. Update component

Changes supported details of an existing component.

Typical use: A component’s name, description, or other available settings need to change.

22. Update epic

Changes supported details of an existing epic.

Typical use: An epic’s scope, planning information, or project association needs an update.

23. Update project

Changes supported details of an existing project.

Typical use: A project’s description, dates, or estimates need to reflect a new plan.

24. Update sprint

Changes supported details of an existing sprint.

Typical use: An iteration’s planning information needs to be revised.

25. Update task

Changes supported details of an existing task.

Typical use: A task’s description, project association, or estimates need updating.

CRM

26. Assign account owner

Sets the owner responsible for an account.

Typical use: Account responsibility should be assigned or handed over.

27. Assign contact owner

Sets the owner responsible for a contact.

Typical use: A named colleague should manage the contact relationship.

28. Assign deal owner

Sets the owner responsible for a deal.

Typical use: An opportunity should be routed to the seller managing it.

29. Assign lead owner

Sets the owner responsible for a lead.

Typical use: New or reassigned leads need a clear person responsible for follow-up.

30. Convert lead

Starts the supported lead-conversion operation.

Typical use: A qualified lead is ready to move into the next CRM stage of work.

Use an eligible lead and the conversion options shown in your CRM; do not assume which linked records will be created or reused.

31. Create account

Creates a company or organization account in the selected CRM space.

Typical use: A new customer or prospect organization needs a CRM record.

32. Create contact

Creates a person’s contact record in the selected CRM space.

Typical use: A new stakeholder should be recorded in CRM.

Creating a contact does not itself send outreach or grant workspace access.

33. Create deal

Creates a deal with supplied opportunity details in the selected CRM space.

Typical use: A potential sale should enter the opportunity pipeline.

34. Create lead

Creates a lead with the supplied prospect information and supported associations.

Typical use: A new prospect needs qualification and follow-up.

Review optional automation settings; record creation and outreach are separate decisions.

35. Link contact to account

Associates an existing contact with an account.

Typical use: A person should be connected to the organization they represent.

36. Link deal to account

Associates an existing deal with an account.

Typical use: An opportunity needs its customer or prospect organization attached.

37. Link deal to contact

Associates an existing deal with a contact.

Typical use: An opportunity needs its relevant contact attached.

38. Link lead to account

Associates an existing lead with an account.

Typical use: A prospect should be connected to a known organization.

39. Link lead to contact

Associates an existing lead with a contact.

Typical use: A lead should reference an existing person in CRM.

40. Log activity

Records a CRM interaction or activity against a selected entity.

Typical use: A call, note, or other interaction needs to appear in the CRM history.

Logging an activity does not by itself prove that a message was sent or a call took place.

41. Set account primary contact

Designates a contact as the account’s primary contact.

Typical use: The main person to approach for an account needs to be identified.

42. Set deal stage

Sets the deal’s stage field.

Typical use: A deal needs a direct pipeline-stage update.

A stage-field update is distinct from running a governed lifecycle transition.

43. Set deal status

Sets the deal’s status field.

Typical use: The deal’s current working status needs to change.

Status and stage are separate fields; use a transition when the configured lifecycle process must advance.

44. Set lead stage

Sets the lead’s stage field.

Typical use: A lead needs a direct stage update.

A stage-field update is distinct from running a governed lifecycle transition.

45. Set lead status

Sets the lead’s status field.

Typical use: A lead’s current working status needs to change.

Status and stage are separate fields; use a transition when the configured lifecycle process must advance.

46. Transition deal

Applies a selected lifecycle transition to a deal.

Typical use: The deal should advance through its configured business process rather than just change a field.

Choose a transition valid from the deal’s current step; its rules can govern resulting stage, status, and approval needs.

47. Transition lead

Applies a selected lifecycle transition to a lead.

Typical use: The lead should advance through its configured qualification process.

Choose a transition valid from the lead’s current step; its rules can govern resulting stage, status, and approval needs.

48. Update account

Changes supported fields on an existing account.

Typical use: Organization details such as region or segment need updating.

49. Update contact

Changes supported fields on an existing contact.

Typical use: A contact’s role, persona, or account association needs updating.

50. Update deal

Changes supported fields on an existing deal.

Typical use: Opportunity details such as name, amount, or owner need revision.

51. Update lead

Changes supported fields on an existing lead.

Typical use: Prospect information needs correction or enrichment without creating another lead.

Chat

52. Add member to channel

Adds a selected user to a chat channel.

Typical use: Someone needs to join the conversation.

Consider the channel history and information the new member may be able to access.

53. Create channel

Creates a chat channel with the supplied settings.

Typical use: A new project or group needs a shared conversation space.

54. Post message

Posts the supplied message to a selected chat channel.

Typical use: A workflow should share an update, handoff, or alert with that channel.

Check the destination and message before enabling an automated posting workflow.

Cobrain

55. Await Act activation decision

Waits for an activation decision on an Act.

Typical use: Later workflow steps depend on the approval or rejection of activation.

Waiting does not request activation or approve the Act; handle the actual decision.

56. Await Act result

Waits for the result of an Act run.

Typical use: Later steps need the outcome of a run that has already been started.

Use the intended run reference; waiting is not the same as starting a new run.

57. Await built-in agent activation decision

Waits for an activation decision on a built-in agent.

Typical use: Later steps must respond to whether the agent is approved for activation.

Waiting does not request or grant activation.

58. Await built-in agent result

Waits for the result of a built-in agent run.

Typical use: Later steps need the outcome of an already-started agent run.

Use the intended run reference; this does not start the agent again.

59. Cancel Act run

Requests cancellation of a particular Act run.

Typical use: An in-progress Act execution should no longer continue.

Cancellation is about the run, not deletion of the Act, and does not imply rollback of completed effects.

60. Cancel built-in agent run

Requests cancellation of a particular built-in agent run.

Typical use: An in-progress agent execution should be stopped.

Cancellation does not imply rollback of effects already completed.

61. Classify content

Uses CoBrain to categorize supplied content.

Typical use: Text needs a category to support routing, triage, or reporting.

Treat the classification as AI-generated and validate high-impact routing decisions.

62. Configure draft built-in agent

Configures a draft built-in agent before activation.

Typical use: An available agent needs its draft settings prepared or revised.

Draft configuration is not activation; keep the required policy and version references aligned.

63. Create draft Act

Creates a draft Act for later review and activation.

Typical use: You want to prepare a reusable AI activity without making it active.

Creating the draft does not activate or run it.

64. Custom Cobrain prompt

Sends a custom prompt through CoBrain and makes its generated response available.

Typical use: Your text-processing task does not fit a more specialized CoBrain node.

Review generated content before treating it as fact or using it for consequential action.

65. Deactivate Act

Deactivates an Act.

Typical use: An Act should no longer remain active for use.

Deactivation is a lifecycle change; use Cancel Act run for a specific in-progress execution.

66. Deactivate built-in agent

Deactivates a built-in agent.

Typical use: An agent should no longer remain active for use.

Use the run-cancellation node when the target is a particular execution.

67. Extract fields

Uses CoBrain to pull requested structured information from supplied content.

Typical use: Unstructured text needs to become fields usable by later workflow steps.

Check missing, ambiguous, or inferred values before updating important records.

68. Generate summary

Uses CoBrain to summarize supplied text, with supported guidance such as tone.

Typical use: A long update needs a concise version for a handoff or report.

Review summaries for omissions and unsupported conclusions.

69. Inspect Act result

Reads the available result information for an Act run.

Typical use: You need to examine a run’s outcome without starting another run.

Use Await Act result when the workflow needs to wait rather than inspect what is available now.

70. Inspect Act state

Reads an Act’s current lifecycle and version information.

Typical use: A workflow needs to check whether an Act is still a draft or otherwise eligible for the next step.

71. Inspect built-in agent result

Reads the available result information for a built-in agent run.

Typical use: You need to inspect an agent run’s outcome without launching it again.

Use the await node when completion must be waited for.

72. Inspect built-in agent state

Reads the current state of a selected built-in agent.

Typical use: A workflow needs state information before deciding what to do next.

73. Meeting transcript summary

Uses CoBrain to summarize meeting transcript content.

Typical use: Meeting discussion needs a concise recap for follow-up.

A generated recap does not by itself create tasks or verify that every speaker’s intent was captured.

74. Pause Act

Temporarily pauses an Act.

Typical use: You want to suspend an Act temporarily.

Do not equate a lifecycle pause with cancellation or rollback of a particular run.

75. Pause built-in agent

Temporarily pauses a built-in agent.

Typical use: An agent should be temporarily suspended.

Use run cancellation when you specifically need to stop an execution.

76. Request activation Act

Submits an Act for an activation decision.

Typical use: A prepared draft is ready for the required activation review.

A request is not approval or execution; handle the decision before running the approved Act.

77. Request activation built-in agent

Submits a built-in agent for an activation decision.

Typical use: A configured agent is ready for the required activation review.

Keep the required version references current; a submitted request does not establish approval.

78. Resume Act

Resumes a paused Act.

Typical use: A temporarily suspended Act should become available again.

This is not a request to replay an earlier run.

79. Resume built-in agent

Resumes a paused built-in agent.

Typical use: A temporarily suspended agent should become available again.

This is not a request to replay an earlier execution.

80. Run approved Act

Starts execution of an approved Act.

Typical use: An authorized, prepared Act should perform its work now.

Use the eligible approved version; starting the run is distinct from receiving its final result.

81. Run approved built-in agent

Starts execution of an approved built-in agent.

Typical use: An eligible approved agent should perform its configured work.

An approved release must be available; inspect or await the run result separately.

82. Suggest tasks from text

Uses CoBrain to propose tasks from supplied text.

Typical use: Notes or discussion need to be turned into candidate action items.

Review the suggested work and confirm any task-creation step separately before assigning or relying on it.

83. Update draft Act

Updates an existing draft Act.

Typical use: An Act’s draft needs refinement before activation.

Use the expected draft version; changing a draft is not activation or execution.

84. Write content

Uses CoBrain to draft content from supplied instructions.

Typical use: A workflow needs a draft message, passage, or other written output.

Review generated content before publishing or sending it.

Control Flow

85. Delay / Wait

Waits for the configured duration before continuing along the workflow.

Typical use: You need to space out steps or postpone a follow-up.

86. Error handler

Routes a connected failure into a recovery path.

Typical use: You want a known failure to lead to a fallback, notification, or other recovery step.

Connect the error path explicitly; handling an error does not undo changes already made.

87. Loop / For each

Runs a connected body for each item in a supplied collection, then follows its completion path.

Typical use: You need the same sequence applied to several records or values.

An empty collection has no body iterations; design the completion path separately.

88. Parallel branch

Starts separate connected branches of work from one point in the workflow.

Typical use: Independent tasks can proceed on separate branches instead of a single sequence.

89. Parallel merge

Provides a joining point for parallel workflow branches.

Typical use: Later work needs a deliberate continuation point after parallel work.

Confirm the configured join behavior; do not assume every incoming branch must finish unless that is the selected contract.

90. Retry

Applies configured retry attempts and backoff to a connected body.

Typical use: A recoverable failure warrants another attempt rather than immediate abandonment.

Avoid blindly repeating actions that can create duplicate records, send messages, or charge money.

91. Stop workflow

Ends the workflow at this point and records the configured reason.

Typical use: A branch has no further work to do or must intentionally stop.

An intentional stop is distinct from an unhandled failure and does not roll back earlier actions.

Desk

92. Add external comment

Adds a customer-facing comment to a ticket.

Typical use: A ticket needs an update intended for its external audience.

Check the text and audience carefully; this is not an internal-only note.

93. Add internal comment

Adds an internal comment to a ticket.

Typical use: Support staff need a private handoff note or internal context.

94. Add watcher

Adds a selected user as a ticket watcher.

Typical use: Someone should follow the ticket without necessarily becoming its assignee.

95. Assign ticket

Assigns a ticket to a selected eligible person.

Typical use: A ticket needs a responsible handler.

96. Close ticket

Closes a ticket using its configured terminal state.

Typical use: The support issue is ready to leave active handling.

The resulting label may be Resolved rather than literally Closed, depending on the desk’s configuration.

97. Escalate ticket

Escalates a ticket through the available escalation action.

Typical use: An issue needs attention beyond its current handling level.

Use the escalation settings offered by the desk; do not assume a particular recipient, priority change, or SLA effect.

98. Reassign ticket

Changes the person responsible for a ticket.

Typical use: A case needs to be handed from its current handler to another person.

99. Remove watcher

Removes a selected user as a ticket watcher.

Typical use: Someone no longer needs to follow that ticket.

100. Reopen ticket

Returns a closed ticket to an available active status.

Typical use: The issue needs further work after closure.

101. Update ticket priority

Changes the priority of a ticket.

Typical use: Its urgency has changed and the support queue should reflect that.

102. Update ticket status

Sets a ticket to a selected supported status.

Typical use: The ticket has reached a new point in the desk’s handling process.

Files

103. Create a document

Creates a document using the supplied title and supported document options.

Typical use: A workflow needs a new document for a report, handoff, or working draft.

104. Create vault folder

Creates a folder in the file vault.

Typical use: Related files need a dedicated place, such as a new project folder.

105. Move file

Moves an existing file to a selected vault folder.

Typical use: A file needs to be reorganized without creating another copy.

106. Share document/folder

Changes sharing for a selected document or folder.

Typical use: Other people need the supported access to that content.

Review the target, recipients, and permission level before granting access.

107. Update document content

Changes the content of an existing document.

Typical use: A workflow needs to refresh a document instead of creating a new one.

Confirm the supported update mode before assuming content will be appended rather than replaced.

108. Upload file to vault

Adds a file to the vault through the node’s supported upload inputs.

Typical use: A workflow-produced or externally supplied file needs to be stored.

Use the source format and destination accepted by the node; do not assume every URL or file type is supported.

Flow+

109. Await workflow result

Waits for the result of an invoked child workflow.

Typical use: The parent workflow cannot continue meaningfully until the child’s outcome is available.

Use the child run reference from the invocation; this does not invoke another child.

110. Cancel child workflow

Requests cancellation of an invoked child workflow run.

Typical use: A parent no longer needs an in-progress child execution.

Cancellation does not imply that the child’s completed effects are undone.

111. Inspect child workflow

Reads the available state of an invoked child workflow run.

Typical use: A parent needs to check a child’s progress or outcome without invoking it again.

112. Invoke published workflow

Starts an eligible published workflow as a child workflow.

Typical use: A shared process should be reused rather than copied into the current workflow.

The target must be published and callable; supply the inputs its entry point expects.

113. Return workflow result

Provides an explicit result from the workflow.

Typical use: A caller or later inspection needs a defined result rather than an implicit last-step output.

Returning a value does not itself invoke another workflow.

Goals

114. Create goal

Creates a goal with the supplied planning details.

Typical use: A new team or business outcome needs a top-level tracking item.

115. Create key result

Creates a measurable key result under the selected objective.

Typical use: An objective needs a concrete measure of success.

116. Create objective

Creates an objective under the selected goal.

Typical use: A broad goal needs a more specific outcome to organize progress.

117. Link work item

Associates a work item with a goal, objective, or key result using the supported link settings.

Typical use: Delivery work should be connected to the outcome it supports.

118. Remove work link

Removes the association between an outcome item and linked work.

Typical use: A task or other work item no longer belongs in that outcome’s supporting work.

This removes the link, not the underlying work item or goal record.

119. Update KR progress

Updates a key result’s progress, with a comment where provided.

Typical use: A measured outcome needs a progress check-in.

Use the input’s stated progress scale; do not assume a current/target ratio is applied automatically.

120. Update goal/objective/KR

Changes supported details of an existing goal, objective, or key result.

Typical use: An outcome’s title or other available fields need revision.

Inbox

121. Move email

Moves an existing email to the selected supported destination.

Typical use: A message should be organized after processing.

Choose the destination exposed by the connected inbox; moving a message is not sending a reply.

122. Send email

Sends an email using the configured sender and recipients.

Typical use: A workflow needs to deliver an email update or response.

Check recipients, content, and sending permissions; repeating the action may send another email.

Integrations

123. Call GraphQL

Calls a GraphQL API using the supplied operation and supported connection settings.

Typical use: Another system exposes the data or operation you need through GraphQL.

Queries and mutations can have different effects; confirm the API’s authentication and operation contract.

124. Call REST API

Calls a REST API using the supported request and connection settings.

Typical use: A workflow needs to exchange data with another system’s REST endpoint.

Check authentication, request shape, and remote write effects before enabling retries.

Meet

125. Add member to room

Adds a selected user to a meeting room’s membership.

Typical use: Someone needs to participate in that room.

Room membership and scheduling a meeting are different actions.

126. Create meeting room

Creates a meeting room with the supplied settings.

Typical use: A team or activity needs a dedicated meeting space.

Creating the room does not itself schedule, join, or record a meeting.

127. Fetch recordings

Retrieves available recordings for a specified meeting.

Typical use: Later workflow steps need to work with an existing meeting recording.

Use a valid meeting reference; this node does not start recording or guarantee that a recording exists.

128. Fetch transcripts

Retrieves available transcripts for a specified meeting.

Typical use: A workflow needs transcript content for a recap or further processing.

Use a valid meeting reference; retrieval does not guarantee that a transcript has been produced.

129. Remove room member

Removes a selected user from a meeting room’s membership.

Typical use: Someone no longer needs access to that room.

Notifications

130. Send notification

Creates a notification for the configured recipients.

Typical use: People need an in-app alert about a workflow event.

A created or available notification does not prove push delivery or that the recipient has read it.

People

135. Approve or reject leave

Records an approval or rejection decision on a leave request.

Typical use: An authorized reviewer’s decision should be applied to a leave request.

Use the correct request and permitted decision; this is a decision action, not just a request for review.

136. Assign a course

Assigns a course to the selected person or supported audience.

Typical use: Someone needs to complete a specific learning course.

Assignment is not evidence of enrollment activity, attendance, or completion.

137. Assign a learning path

Assigns a learning path to the selected person or supported audience.

Typical use: Someone needs a structured set of learning activities.

An assigned path is not a completed path.

138. Register for training

Registers the selected person for an available training offering.

Typical use: A person should be enrolled in a specific training opportunity.

Registration is not attendance or completion; use an eligible offering and participant.

Procure

139. Create purchase order from approved request

Creates a purchase order from an eligible approved purchase request.

Typical use: An approved request is ready to become an order.

Approval is a prerequisite; creating the purchase order is not proof of supplier acceptance, payment, or delivery.

System

140. Delay

Pauses this workflow for the configured duration.

Typical use: You need a time gap before the next step, such as a short follow-up delay.

141. HTTP request

Sends an HTTP request to a configured URL and exposes the response for later steps.

Typical use: You need to retrieve data from or send data to an HTTP endpoint.

A remote change may occur even if the overall workflow later fails; check the remote outcome before repeating a write.

142. Webhook response

Provides the response associated with an incoming webhook request.

Typical use: The system calling your webhook needs a workflow-controlled reply.

Use with the webhook intake flow; confirm its supported response fields and timing before relying on a synchronous reply.

Before enabling your workflow

Check the saved node inputs, the selected records and the connected paths. Test matching and nonmatching cases. Inspect the run output and the destination record or message before relying on the automation. If a run reports an uncertain outcome, check what already happened before starting it again.

For a guided walkthrough, continue with Flow+ course 02 — Configuring a complete draft and checking its saved definition, then Flow+ course 03 — Distinguishing Preview, Test Run and verified outcomes.

Turn what you learned into the way the team works.

Mark this lesson complete once the workflow exists in your workspace—not simply when you reach the bottom.