How to Change Flow Direction

Unito syncs fields between work apps and tools by default, but you can change that in just a few clicks.

Table of contents:

What is flow direction?

Flow direction determines where Unito will automatically generate new work items (e.g., tasks, tickets, issues, spreadsheet rows, etc...) in one or both connected tools. Your data can sync from either one work app or tool to the other, or bidirectionally. Flow direction is the difference between them.

Here’s a breakdown of each option:

  • One-way flow: only work items created in the source tool will appear in the destination tool.
  • Two-way flow: works items created in either tool will appear in the other.

Example: imagine a flow between a Trello board and a GitHub project. Unito could be told to create new Trello cards based on GitHub issues and new GitHub issues based on Trello cards, while keeping them all synced in real-time. That's a two way flow.

Alternatively, you could tell Unito to only create new Trello cards based on specific GitHub issues, and not to create GitHub issues based on Trello cards. That's a one-way flow.

Changing flow direction for work item creation

When you get to the flow direction screen, you'll see the double arrow option highlighted, representing a default two-way sync:

In the above example, Trello and GitHub can create work items in the other through a two-way sync based on rules you set for Unito. 

To change this to one-way, you can simply click on either of the single-direction arrows. Then, new work items will only be created in the destination tool based on the source tool:In this example, new Trello cards will turn into GitHub issues, but not the other way around. That's a one-way sync.

Changing flow direction for updates

Unito can map most fields by default with our auto-mapping feature. Some fields will be pre-set to sync in both directions, while others can only sync in a single direction.Unito Two-Way Field Mappings Master

In this case, a URL for the synced GitHub issue or Trello card will appear in the description footer of the other so that users can switch between tools if they so choose.Trello attachments will appear in the GitHub issue's description footer, and every other field is set to a two-way sync.

At this level, you're controlling how changes are synced between tools. So if anyone edits the details of a field in the source, the destination will update automatically. 

Changing flow direction for field mappings doesn't affect work item creation. It only affects the direction in which updates will flow.

A note on flow direction

With most fields, you can choose between setting up a two-way or one-way mapping. However, some fields can only be synced in one direction, while others are limited to two-way mappings. In some cases, this is due to a technical limitation. In others, this is inherent to the nature of the field.

Unito One-Way Field Mappings

Example: Although the initial comments, description and title synced correctly between Trello and GitHub, if anyone edits the description or comments in GitHub, those changes won't appear in Trello. But if edits are made in Trello, then they would appear in GitHub. Edits to the title, in this case, will be seen by teams in both tools. 

What is a one-way create, two-way update flow?

Since you can specify flow direction at two stages of your Unito flow - for both work item creation and updates, you can build a one-way create, two-way update flow. This enables Unito to create work items (tasks, tickets, etc.) in one tool based on details in another, while changes made to that newly created work item can be copied back to the original tool.

Let's take that Trello-GitHub example from before:Unito Two-Way Field Mappings

In this case, any changes made to the comments, description, or title in either Trello or GitHub will be visible to teams in the other tool. So even though our flow is one-way from Trello to GitHub, changes to the synced cards and issues can be set to a two-way sync. 

That's the essence of it. With a one-way create, two-way update flow, you can keep the influx of new work items going just one way, while updates can still go back and forth.

Did this answer your question?