Ziflow Zibots are prebuilt actions you can add as steps in your automation flow to perform tasks in Ziflow, like adding reviewers, updating properties, sending emails, or managing versions. In order to see Ziflow Zibots, you need to connect to the Ziflow application.
Select a Ziflow Zibot to learn what it does and the fields it uses.
|
Add or update proof integration property Search proofs by integration properties |
Update proof custom property
Use to set/change the value of a custom property on a proof. Custom properties in Ziflow are metadata fields you create and define as needed such as “Project Code,” “Campaign Name,” “Department,” or “Priority”. This Zibot lets you update them without manually editing the proof’s details.
- Sets or changes the value of a specified custom property on a proof.
- Works for both text and list-type custom properties.
- Can be run by any event in a flow
Note: To choose custom properties and property groups you must create and define them first. See Add custom proof properties and tags.
Use it to:
- Improve search and reporting: ensure proofs have consistent, up-to-date properties for filtering and analytics.
Examples:
- Integration mapping: After an Air Table task ID is received, update the "Task ID" custom property in Ziflow.
- Internal automation: Use Country and Asset type properties to automatically move a proof into the correct folder.
- Auto-tag a proof with a custom property when it is uploaded from a specific folder.
| Field | Description |
| Select custom property group | Select the property group (e.g., Proof details) |
| Select custom property | Select the custom property to update. After selecting it, configure the additional fields that appear based on your choice. |
Add or update proof integration property
Use to link a Ziflow proof to external systems by adding or updating integration-specific fields.
- Add proof integration property: Used to create the initial connection by populating fields like Task ID, Board ID, File ID, or Channel ID with values from systems such as Basecamp, monday.com, SharePoint, ClickUp, or Slack.
- Update proof integration property: Used to fill in or update those fields after the external system action occurs, for example, inserting the task or ticket ID generated by the external tool back into the proof.
- If the person uploading a proof forgets to link it to your project management tool during upload, set up a duplicate flow with update proof integration property event to ensure that the automated details are still sent to the PM tool. This works with most tools, with the exception of monday.com which requires a more customized solution.
Use it to:
- Keep your proof in sync with corresponding records or tasks in other apps.
- Enable automation flows that connect Ziflow reviews with project management, file storage, or communication tools.
- Track and reference external items directly from within your proofs.
Examples:
- Basecamp: After creating a proof, use this Zibot to add Basecamp to-do IDs (Account ID, Project ID, Todo ID, etc.) to the proof, or update them once created.
- SharePoint: Upload a proof to SharePoint and then add the SharePoint Site ID and File ID into the proof’s integration properties.
- monday.com: Link proofs to monday.com boards and items by inserting their IDs into integration fields.
- ClickUp: Designer forgot to input the PM tool task ID at the time of upload
- Slack / Teams: Add channel or team identifiers to proofs after sending notifications via Slack or Teams.
| Field | Description |
| Proof ID |
The unique identifier of the proof you want to update. Usually a dynamic value from your flow, like {{proof.id}} or a specific proof ID if hardcoding. This tells the Zibot which proof to add or update the integration property on. |
| Select application |
The external system or app you’re integrating with. Choose the app that owns the integration property you want to update (e.g., Basecamp, SharePoint, ClickUp, monday.com, Slack). This scopes the properties and values to that system. Note: If you have connected the app but do not see it in your list, go to the Connect tab, open the connection, and in Settings, select Show next to Applications fields on a proof. |
| Select connection |
The specific authenticated connection or integration setup between Ziflow and your external app. Pick the configured connection that has credentials and permissions to access the external system’s data. If you have multiple connections (e.g., for different accounts or environments), select the relevant one here. |
| Select integration property group |
A grouping of related integration properties, often representing a category or section inside the proof’s integration metadata. Choose the logical group or category your property belongs to, like “Basecamp Task IDs” or “SharePoint File References.” This helps organize integration data cleanly inside proofs. |
| Select integration property |
The integration property (field) you want to add or update on the proof. Select the property name (e.g., Task ID, Project ID, File ID, Channel ID) that matches the data you will supply. This is the key that identifies what information you’re storing. |
| Integration property value |
The value you want to write into the selected integration property. The unique identifier or code from the external system, such as a task ID string, file ID, or channel name. This value links the proof to the corresponding external record. |
| Labels |
Optional tags you can add for extra organization, filtering, or reporting inside Ziflow. Use any relevant labels or keywords that help you categorize or find proofs later. For example, “marketing,” “Q3 campaign,” or “urgent.” These don’t affect the integration but improve search and management. |
Search proofs by integration properties
Use to find proofs in Ziflow that match the integration property criteria you specify.
Those properties are the same ones you populate when linking proofs to external systems (Task IDs, Project IDs, Board IDs, Channel IDs, etc.). Where Add/Update Proof Integration Property writes data into a proof’s integration fields, Search Proofs by Integration Properties reads those fields and filters proofs accordingly.
Use it to:
- Find the right proof to update, e.g., you get an event from monday.com or Basecamp with a Task ID, and you want to update or comment on the corresponding proof in Ziflow.
- Start follow-up actions, e.g., if a proof linked to a certain project in ClickUp needs to be sent to SharePoint, the Zibot first searches for it using the Project ID stored in its integration properties.
- Avoid duplication: you can check whether a proof already exists for a given external record before creating a new one.
Examples:
- Basecamp: You have a Basecamp to-do ID and want to add a comment to its linked proof in Ziflow. Use this Zibot to find the proof by that Basecamp ID.
- SharePoint: A file gets replaced in SharePoint and starts a webhook. Your flow searches for the matching proof by its stored SharePoint File ID.
- ClickUp / monday.com: An update happens to a task/item in those systems, and the Zibot searches Ziflow to find the corresponding proof before running more actions.
| Field | Description |
| Select application |
The external system or app you want to search by. Choose the app you integrated with (e.g., Basecamp, SharePoint, ClickUp, monday.com, Slack). This narrow the search to that system's data. |
| Select integration property group |
A category or grouping of integration properties related to the chosen application. Pick the logical group that contains the property you want to search on, such as “Basecamp Task IDs” or “ClickUp Task Info.” |
| Select integration property | The specific integration property (field) that you want to use as your search filter. Choose the exact property name, for example, “Task ID,” “Project ID,” or “File ID”, the field whose value you will match to find proofs. |
| Integration property value |
The value you’re looking for in the selected integration property. The exact ID, code, or string from the external system (e.g., a specific task ID or file ID) that you want to find in your proofs. |
Check multiple stages statuses
Use to evaluate the review stages of a proof and decide what happens next in your automation.
It looks at two or more review stages on a proof and compares their statuses (Approved, Changes Required, Pending, etc.) to the conditions you set. If the stages match the criteria, the flow continues; if not, it either stops or follows a different path (depending on your flow setup).
For example, How Do I Trigger a Stage Based on Another Stage's Decision Status?
Use it to:
- Only proceed when all required teams have approved a proof.
- Start alternative actions, for example, if any stage has “Changes Required,” automatically notify the project manager.
- Coordinate multi-team sign-off — marketing, legal, and product design all need to approve before a file goes to final delivery.
Examples:
- Final approval routing: Wait until both the “Design Review” and “Legal Review” stages are marked Approved before sending the file to print.
- Conditional branching: If any stage rejects the proof, create a Jira task for revisions; otherwise, upload to SharePoint.
- Progress tracking: Combine this with a notification Zibot so stakeholders know when all their assigned stages have completed.
| Field | Description |
| Find all stages starting with text |
A text filter to identify which stages to check based on their names. Enter the starting characters of the stage names you want the Zibot to evaluate. |
| Include number of trigger stage after the search text |
|
| Select status |
The status condition(s) you want the matched stages to meet to trigger the flow continuation. Choose one or more statuses (e.g., Approved, Changes Required, Pending). |
| Or select status |
Additional status options to widen the condition for matching stages. Select alternative statuses that also qualify for the condition. |
Start a stage
Use to start stage on a proof that you can't set up in a workflow. It takes a stage you’ve already set up in the proof’s workflow and activates it and sends notifications to the stage’s assigned reviewers.
Use it to:
- Automate review sequence timing, for example, start the legal review stage immediately after the design stage is approved.
- Avoid delays: ensure the next group of reviewers gets the proof as soon as conditions are met, without waiting for someone to remember to start it.
Examples:
- Sequential reviews: After “Marketing Review” is approved, the Zibot starts “Legal Review.”
| Field | Description |
| Find and start all stages starting with text |
A filter that tells the Zibot which stages to start based on their names. Enter the beginning text of the stage names you want to activate. The Zibot will find all stages whose names start with that text and automatically start them in the proof. Example: If you enter Legal, it will start all stages named “Legal Review,” “Legal Approval,” etc. |
Add reviewer
Use to add reviewers to the chosen stage and select reviewer proof permissions and notification preferences. Choose their permissions, the stage they belong to, and notification settings.
Works for both active and yet-to-be-started stages in a proof’s workflow.
Use it to:
- Add the correct reviewer when a proof reaches a certain stage or meets a condition.
- Bring in reviewers only when their input is needed, based on proof status or content changes.
Examples:
- External consultant: If a proof is tagged “Compliance,” automatically add a compliance officer as a reviewer.
- Late-stage input: Add a marketing lead only after product images have final approval from design.
- Add a reviewer through intake form submission
| Field | Description |
| Stage |
The review stage within the proof’s workflow where you want to add the reviewer. Select the stage where the new reviewer should be assigned. |
| Select reviewer to add to stage |
Choose who gets added as a reviewer for the chosen stage.
Note: If the proof’s security is set to “Users only”, guest reviewers (added by email who aren’t licensed users) will not be added. |
| Permissions |
Defines what the added reviewer can do on the proof.
|
| Notifications |
Defines which updates and alerts the reviewer receives by email.
|
Turn minor version on/off
Use to turn on/off a minor version on a proof level.
- Major: The next version will be a full version increment (e.g., from v1 to v2).
- Minor: The next version you create will be labeled as a sub-version (e.g., v1.1, v2.1) instead of jumping to the next full version number (v2, v3).
Use it to:
- Iterate on small changes that don’t justify a full version bump, like fixing typos or adjusting image contrast.
- Automating version control policy, e.g., use a minor version for internal review changes, but a full version when client review restarts.
- Integration with other tools to keep numbering rules consistent across systems that also track versions.
Examples:
- Internal edit loop: If a proof comes back with “Changes Required” from only the design stage, automatically turn minor version ON before uploading the revised file.
- Final stage approval: When all stages approve, turn minor version OFF so any future changes become full versions for archival clarity.
- Different review paths: Use minor versions for pre-launch edits, full versions for post-launch updates.
| Field | Description |
| Change proof versioning to |
Defines how the next proof version number increments.
|
Replace/Append workflow
Use to swap out or add to the review workflow on an existing proof. See Create and use workflow templates.
- Replace workflow: Removes the current workflow (all stages, reviewers, deadlines) on the proof and applies a new predefined workflows you’ve already saved in Ziflow’s Workflow Templates.
- Append workflow: Keeps the existing workflow but adds the stages from another workflow to the end (or in sequence if set up that way).
Note: The number of allowed stages in a proof is based on your Ziflow edition, so if you attempt to append or replace a workflow that goes beyond the maximum stage limit, the flow will fail.
Use it to:
- Change review requirements mid-stream, e.g., the client requests a compliance check after initial reviews have started.
- Branch review paths: If a proof fails approval, append a “Rework Review” workflow instead of starting from scratch.
Examples:
- Replace: The proof starts with a 2-stage internal workflow, but after stakeholder input, you replace it with a 4-stage external review workflow for the next version.
- Append: Once the Marketing Review stage finishes, automatically append a Legal Review stage from a saved workflow.
- Custom triggers: Append an “Urgent Review” workflow when the due date is moved up in your project management tool.
| Field | Description |
| Select workflow |
The predefined workflow template you want to apply to the proof. Choose the saved workflow that contains the stages and reviewers you want to use to replace the current workflow or append to it. |
| Select connection |
The integration or account connection tied to the workflow, if applicable. Pick the connection that authorizes access to the external system or environment relevant to the workflow (if your setup uses multiple integrations). |
| Select if you want to append stages to the proof or replace with the workflow |
Defines how the selected workflow is applied to the proof.
|
Send Email
Send email notifications when a flow event is started. Sends a plain-text or HTML-formatted email from Ziflow to one or more recipients. It can be started by any flow event, proof created, stage approved, integration update, webhook, etc.
The email can include static text, dynamic proof details, or both.
Use it to:
- Customize notifications beyond Ziflow’s standard system alerts.
- Target communications only to certain stakeholders based on proof status, stage results, or integration data.
- For integrations without native connectors, use email as a fallback to push updates to systems that can accept inbound email.
Examples:
- Client update: When a proof is approved, send a polished summary email to the client.
- Internal alert: If legal rejects a proof, notify the project manager and design lead immediately.
| Field | Description |
| From name | provide a name that you would like to appear in the "from name" field of the email. You can also use a token selector to automatically input the email address of the proof owner. |
| From email | select a "from email" that the message should be sent from. If you have configured your own custom domain mapping, you should be able to select email from your domain configuration. |
| To recipients | enter email address/s manually or select them using a token selector. |
| Subject | input a subject line for your email. |
| Message |
Compose your email message. You can use the token selector to insert metadata, such as proof details, for added context. A simple HTML version of our template is provided below. To customize it, select Source view in the WYSIWYG text editor, and edit the HTML as needed. You can adjust the template to match your requirements. |
| CC recipients | include additional recipients by adding them as carbon copy recipients to your email. |
| BCC recipients | to add more recipients to your email, you can include them as BCC recipients. |
| Reply to | it's important to set a designated "reply to" address to ensure that any email responses go to the right place. |
Email template
The HTML code provided is a starter template for building your own email designs. Because this is custom code, it is outside the scope of Ziflow Technical Support. For advanced customization or additional help, contact your Ziflow account representative. They can assess your needs and coordinate with our Client Services team if required.
When creating email templates, consider using tokens to insert dynamic information. For example, the token #{$.proof.public_link}# automatically adds the proof link. See What are tokens and how do I use them?
<div style="background:#f9fafc;color:#38444c;font-family: 'Proxima Nova', Helvetica, Arial, sans-serif; font-size: 16px;font-weight:normal;letter-spacing: -0.2px; line-height: 1.6;height:100%;line-height:1.6;margin:0;min-width:600px;padding:0;text-align:left;vertical-align:top;width:100%">
<div style="max-width: 600px; margin: 0px auto; background-color: #f9fafc; padding: 0; padding-top:40px !important; font: inherit;">
<div style="font: inherit; padding: 20px;">
<div style="font-weight: bold">Hi Reviewer,</div>
<div>You have 1 new proof to review.</div>
</div>
<div style="background: #ffffff; padding: 16px 0px;">
<table style="background: #ffffff; border:#ffffff; border-collapse: collapse; border-spacing: 0; display: table; padding: 0px !important; position: relative; text-align: left; vertical-align: top; width: 100%;">
<tbody>
<tr style="padding: 0; text-align: left; vertical-align: top;">
<td style="border: 0; background: #ffffff; margin: 0; padding: 0; vertical-align: top; width: 16px;"></td>
<td style="border: 0; height: 115px; margin: 0; overflow: hidden; padding: 0px !important; width: 115px;">
<p style="background-color: #f3f3f3; margin: auto; margin-bottom: 0; margin-top: 0; max-width: 115px; padding: 0; text-align: center;">
<img src="#{$.proof.thumbnail_link}#" alt="Proof Thumbnail" style="-ms-interpolation-mode: bicubic; border: none; clear: both; display: block; height: auto; margin: auto; max-height: 115px; max-width: 100%; outline: none; text-decoration: none; width: 115px;">
</p>
</td>
<td style="border: 0; height: 80px; line-height: 1.6; margin: 0; padding: 0; padding-left: 20px; text-align: left; vertical-align: top; word-wrap: break-word;">
<p style="display: table-cell; font: inherit; font-weight: bold; line-height: 18px !important; margin: 0; padding: 0; text-align: left; word-break: break-word;">
#{$.proof.name}#
</p>
<p style="color: #38444c; font: inherit; height: 18px !important; line-height: 18px !important; margin: 0; margin-bottom: 8px !important; margin-top: 8px !important; padding: 0; text-align: left;">
<span style="background-color: #d8d8d8; border-radius: 4px; font-size: 12px; font-weight: bold; margin-bottom: 0px !important; opacity: 0.7; padding: 2px 10px;">
V#{$.proof.versions[0].version}#
</span>
</p>
<div style="margin-bottom: 10px;">
<a href="#{$.proof.public_link}#" style="-webkit-text-size-adjust: none; background-color: #096ff6; border: 1px solid #096ff6; border-radius: 4px; color: #ffffff; display: inline-block; font-family: sans-serif; font-size: 13px; font-weight: bold; line-height: 30px; margin: 0; padding: 0; padding-left: 15px; padding-right: 15px; text-align: center; text-decoration: none;">
Open proof
</a>
</div>
</td>
<td style="border: 0; background: #ffffff; margin: 0; padding: 0; vertical-align: top; width: 16px;"></td>
</tr>
</tbody>
</table>
</div>
<div style="margin-top: 16px;padding-bottom: 16px;height:16px; text-align: right;">
<img src="https://d2u0rt0nzribkz.cloudfront.net/Assets/current/img/v5/logo.png" alt="Ziflow" height="16" style="height:16px;max-height:16px;max-width:100%;outline:none;text-decoration:none;vertical-align:baseline!important;width:auto">
</div>
</div>
</div>
Comments
0 comments
Please sign in to leave a comment.