Skip to content

Collaborate: Versions, Compare, and Share

~25 minutes · a version history, a comparison, a shared link

When several people work in the same project, the questions that matter on day one are always the same: What changed? Can I get an earlier state back? How do I move a change from one project to another? How do I send a teammate straight to the thing I’m looking at? PlaidCloud answers all four out of the box — work is versioned, comparable, and shareable, and this tutorial walks you through each one.

The message to leave with: nothing gets lost. Every change is tracked, any two projects can be compared, and every screen has a link.

  1. See a project’s automatic change history and read its log.
  2. Compare two projects and understand what a merge does.
  3. Organize work with labels so you can find it again.
  4. Copy a deep link that sends a teammate to an exact place.
  • A PlaidCloud workspace and a project you can open.
  • A second project — a copy or a QA/Production counterpart — if you want to try the comparison on real content. A copied project works well.

Everything you build in a project is tracked for you — you don’t turn this on.

Nothing gets lost. All changes to a project — workflows, data editors, hierarchies, table structures, and user-defined functions — are tracked and allow point-in-time recovery of the state. That means an accidental change can be recovered, and any earlier point can be copied out for comparison.

On top of that automatic tracking, projects and their elements support versioning: creating a version is easy, and you can merge changes from one version to another. It’s a simple way to keep snapshots, or to develop in one version and merge those changes into the non-development version when you’re ready.

The Project Log consolidates every individual workflow log into one comprehensive view of project activity — members assigned, workflows run, and more.

  1. Open Analyze.
  2. Select Projects.
  3. Open the Log tab (the project log).

To narrow a busy log, use the filter control next to the log messages and choose your filter guidelines. To read one entry in full, right-click it and view the Log Message box.

Clearing the log deletes the sub-logs too. The Clear Log button removes the Project Log and every workflow’s sub-log beneath it. Clear it only when you truly want that history gone.

Comparison lets you see exactly what differs between two projects and, for the parts that can be safely copied, merge selected changes from one into the other. It fits two everyday situations: promoting changes between environments (a QA project into its Production counterpart) and reviewing against an earlier copy (a month-over-month clone, to see what changed).

You stay in control the whole way — nothing is written until you select specific items and apply them, and you can validate first with a dry run.

  1. Open Analyze and select Projects.
  2. Right-click the project you want to start from (or use its actions menu) and choose Compare to….
  3. The project you started from is filled in as the Source. Choose the Target from the dropdown.
  4. Click Compare.

Both projects must be in the same workspace. Use Swap to reverse Source and Target before comparing — direction matters, because a merge copies from Source into Target.

Sourcewhere changes come fromTargetthe project that changesmerge copies →
A merge only ever writes into the Target. Get the direction right before you apply.

The left side groups every difference under its category — Workflows (with Steps nested), Variables, Dimensions, Editors, UDFs, Views, and Tables. Each item is badged with its status:

Badge Meaning
Added In Source but not Target — it would be created in Target
Modified In both, but the configuration differs
Deleted In Target but not Source
Unchanged Identical on both sides (hidden by default)

Select a changed item to see a Field / Source / Target table on the right, with the full Config diff beneath it. Filter by name or path, or toggle the status checkboxes, to focus a long list.

Not every difference can be safely copied, so the comparison labels each item:

  • Workflows, Steps, and Variables can be merged.
  • Dimensions, Editors, UDFs, Views, and Tables are view-only — review them here, but copy them across with their own dedicated tools.

To merge, select the mergeable items, click Dry run to validate without writing, then Apply and confirm. Merged items keep their identity in the Target, so you can compare again later and merge further changes without creating duplicates.

A merge changes the Target. Review the diff, run a dry run, and confirm Source and Target are the right way around before you apply. If someone else edited the Target after you loaded the comparison, the merge stops rather than overwrite their work — refresh and reapply.

For promoting Dev → QA → Production between projects copied from one another, see Re-syncing From the Project You Copied From, which pairs items by their copy lineage instead of by name.

Labels are free-form tags you attach to objects — the project itself, its workflows, steps, tables, dimensions, data editors, and UDFs. Use them to group related items by whatever matters to you (a phase of work, a source system, an owner, a release) and find them again fast.

Every taggable object has a Labels box in its detail panel:

  1. Click anywhere in the Labels box to place the cursor.
  2. Type the label text.
  3. Press Enter (or type a comma) to add it.

Remove a label with the × on its chip, or press Backspace with the entry field empty to drop the last one.

Labels are stored in lowercase. PlaidCloud lowercases each label automatically and refuses a duplicate on the same object. Keep your set consistent and it becomes a lightweight way to slice a large project.

To find tagged items, type the label into a project list’s filter box — the search matches label text along with the item name.

PlaidCloud keeps the address bar in step with what you have open. Open a workflow, table, or dimension, and the URL becomes a deep link to it. There is no separate share button — the address bar is the link.

  1. Open the object you want to share.
  2. Copy the whole URL from your browser’s address bar.
  3. Send it on — whoever opens it lands on the same screen.

Links are project-first: the project comes first, then the object inside it, separated by ~.

Screen Link ends with
Project #p~<project>
Workflow (Steps grid) #p~<project>~w~<workflow>
Workflow (Visual Workflow Designer canvas) #p~<project>~c~<workflow>
A step inside a workflow …~w~<workflow>~s~<step>
Table Explorer #p~<project>~t~<table>
Dimension hierarchy #p~<project>~d~<dimension>
Data editor #p~<project>~e~<editor>

Opening a link restores the parent context, not just the one window: a link to a workflow reopens its project too, so the recipient arrives with the surrounding project in the tab bar. A step link even selects the step for them.

A link carries the location, not permission. Whoever opens it still needs access to the project. Someone without it won’t see the object — so sharing a link is safe. Control who can see what in Control Data Access.

Older #te?p=…&t=… style links still work and quietly rewrite themselves into the current, more readable form on first navigation.

Nothing gets lost — and now you can show it. You’ve read a project’s history, compared two projects and merged safely in one direction, organized work with labels so you can find it again, and handed a teammate a deep link that drops them exactly where you are.