When creating a new Flow, you will face a three-step interactive UI to guide you through the configuration. The first step is for the General Settings that will show either the Push or the Pull settings:





Common settings

  • Name: The name is used in the administrative area to identify Flows and it can be changed later. The machine name used for the config entity of the Flow is created automatically based on the name, but can be customized under Advanced Settings. If you have multiple Flows on a site that are configured to Pull content Manually, editors will also see the name of the Flow in a drop-down in the Pull dashboard to select the Flow to pull content through.
    • Tip: Use names that are specific enough but as broad as possible. E.g. if you only have one Push or Pull Flow, you can just call it Push or Pull. If you handle articles differently compared to events for example, you could have a Pull Articles and another Pull Events Flow. Making these longer than needed can become confusing later if you need to change the workflow, e.g. the "Push Articles Manually" may be changed to push immediately but the machine name can't be changed later, potentially confusing other site builders.
  • Purpose: Whether you want to Push or Pull content with this Flow. If you want to do both, simply create two Flows.
  • Restrict Pools: Pools are used to group sites so you can route content to only a subset of sites. If all of your sites are receiving the same content, you can just keep the default Content pool and assign it automatically. You can create as many Pools as you need. You can also use taxonomy terms instead of Pools if you prefer- in that case you also just use the default Content pool and automatically assign it.



Push settings

  • Assign Pools: Whether editors can opt-in the Pools that are assigned to content or whether the Pools should be assigned automatically. If you only have one Pool, choose Assign All to save editors from the unnecessary extra work. Content that is not assigned any Pool won't be pushed at all.
  • Push changes: Whether or not editors can control when to push content. If it's set to Immediately, content is pushed as soon as a create or update is detected through Drupal's entity_create and entity_update hooks. If it's set to Manually, editors can save content locally and then Push it anytime later; when using the Manualmode, editors also see a confirmation dialog where they can select the translations to push.
    • If you are using an import script to create content, use Immediately to share the imported data with other sites as soon as it becomes available (only works with auto-assigned Pools).
    • If you want to use the Scheduler module or similar to schedule publishing, use Immediately and restrict content to only be pushed when it's published (already on by default, can be changed under the Advanced settings).


Pull settings


  • Pull new content: Whether or not editors pick and choose per content item what to add to their site or whether all content is added as soon as it becomes available in the selected Pools. When selecting Manually, editors can use the Content Cloud tab at the admin / content page, to search through all available content and add it to their site with the click of a button.
  • Pull Updates: how updates from the source site should be handled:

    • Forbid local changes and update: Don’t allow editors to make any changes on content that was pulled from another site. Recommended for content staging and a general master-slave approach.

    • Update unless overridden locally: The best of both worlds. By default, changes from the source site will be pulled and replace the outdated content on the site. However, editors can explicitly override content to customize it- in this case the flagged content won’t be updated by remote changes and local changes will persist. See here for more details: Override content locally.

    • Create unpublished revisions: Only available for node bundles that are configured to create new revisions on every update. If set, pulled updates will always create a new unpublished revision, allowing your editors to review all changes per site before publishing them. You can use Drupal’s built-in and customizable review processes just as you would with locally created content.

    • Ignore updates completely: After a content item has been pulled, it will never be updated from changes on the source site and is completely decoupled. You can make any changes locally and they will persist.

    • Dismiss changes: Editors can make changes to content that has been pulled from a remote site. If the remote site pushes an update however, all local changes will be lost. Not recommended for most people as this can be confusing for editors and lead to data loss. If you want to use this, consider incorporating a cross-site content locking mechanism.