Intuify

Intuify

Documentation

Builder20 min read

Collaboration & Sharing

Share surveys with teammates, roles, and live editor presence.

On this page (12 sections)

Work with teammates on the same survey — shared access, roles, and live presence in the builder.


Sharing a survey#

  1. From the Surveys list, click Share in the survey's row — it is one of the icons at the right of the row — or use Share in the builder toolbar.
  2. Search for teammates in your organization.
  3. Assign a permission level and confirm.

Collaborators see the survey on their dashboard according to their role.


Permission levels#

LevelWhat they can do
ViewOpen the survey and view responses
EditChange questions, logic, settings, and publish

Organization roles (admin, editor, etc.) still control which features a user can access globally.


Live presence#

When more than one person has the survey builder open, you'll see live presence indicators — who else is editing right now. People who only have the survey open to look at it (for example in preview) are listed under Viewing.


Editing together (live editing)#

With live editing, several people can work in the same survey at once without overwriting each other. It is on for everyone — there is nothing to switch on.

What you see#

  • Changes appear live. A question, option or section a teammate adds or changes shows up on your screen within a second or two. Only what changed is updated, so the rest of the builder stays where you left it.
  • "Name is editing". The question a teammate is working on shows their name. While they hold it, that question is view-only for you everywhere you could change it — the question card, its Properties panel, its item in the Flow tab, and Delete, Duplicate, Move and Reset font sizes in its menu, which names who is editing. If the lock arrives while you have that menu open, clicking one of them changes nothing and tells you "Name is editing Q5". You still see their changes as they type. Every other question, including the others in the same section, stays editable.
  • The lock frees itself. The question becomes editable for you as soon as your teammate moves to another question, closes the survey or loses their connection — or automatically after 2 minutes in which they have not typed or clicked in that question. You don't need to ask them or click anything. If it was your lock that was released, you'll see "Your edit lock on Q5 was released after 2 minutes of inactivity"; click back into the question (or leave it and come back) to carry on (if someone else has started on it meanwhile, it shows their name instead). Nothing you typed before is lost. If you tried to work in something while a teammate held it, you are first in line: it becomes yours when they let go.
  • The survey's creator can take over. When your organization allows it, the person who created the survey sees Take over on any lock, for the moments when a teammate left something open and cannot be reached.
  • Section headers and survey-wide tabs work the same way. A section someone is working on — its title, its Section Properties, its Section Logic in the Flow tab, or its Randomize questions and Section Loop dialogs — and the Flow, Translations, Panels (with quotas) and Settings tabs, are view-only for others with a banner while one person works in them. In the Flow tab you can still open every section's questions to read them (Show all questions). The Translations tab covers everything on it — the translations, the language list, the base language and system-message translations — so a teammate in Settings never blocks it.
  • Changes that need a locked area say so. A change that would also write something a teammate is holding (for example a row text size, which adds a rule to the survey's Custom CSS while someone is in Settings) is not applied, and you are told "Name is editing survey settings" — nothing is half-applied. A choice text size needs nothing from Settings and always applies.
  • Dialogs count as part of what you opened them from. Typing or clicking in the condition builder, a quota, a panel or any other dialog counts as working in that question or tab, so your lock is not released while you work in it, however long a rule takes. If someone else does get the lock (for example after you left a dialog open for more than 2 minutes without typing or clicking in it), the open dialog says who is editing and becomes view-only: click Close, or wait until they finish and carry on — what you had chosen in the dialog is still there.
  • AI changes wait too. If the AI assistant changes something a teammate is editing (a quota, the flow, a question), that part waits for them instead of overwriting their work, and the assistant's reply says so: "Not in the project yet: 1 change waits for Name, who is editing quotas." It is applied when they finish.
  • Updates to what a teammate is editing wait for them. Some changes also update another part of the survey: adding a choice copies it into a question that carries it forward, switching a question's type points every rule at the new question, deleting a section updates the Flow tab. If a teammate is editing that other part, your change goes ahead and only that update waits: you see "Name is editing Q5", and it is applied as soon as they finish. Switching a question's Selection Type or Text Length while a teammate is editing a question that uses it is not a delete: you see "Q1 was switched to Single Select (now Q9)" and everyone else "Name switched Q1 to Single Select (now Q9)", each with what will follow (for example "Q2's carry forward will point to Q9 once nobody is editing it."). If they changed the same thing meanwhile, you choose Use mine or Keep theirs. Until it is applied, Publish waits too and says why: "Part of your last change is waiting for Name to finish editing. Until it is saved, parts of the survey do not match yet. Publish again once they have finished." The same holds for everyone else: while a choice copied into a carried-forward question is still waiting, nobody can publish the survey, the teammate who has that question open included, and neither can an integration. They see "Carried choices do not match their source yet: Q2 (from Q1)…", and nothing is published. Publish again once the update has been applied (it is applied as soon as whoever has the question open moves on). If nothing is waiting any more (for example the update was discarded), open that question's Carry Forward and apply it again to refresh its choices. Deleting a question is different: rules that use it are not cleared. You are told "Q2 is still used", and Publish stops, naming the rule (for example "Q5: display logic refers to a question that has been deleted") with a Go to question button. Fix or remove the rule, then publish. The stop is only for a problem that is new since the survey was last published: if the same rule was already broken in the published version, the survey is published and you get a warning naming it, with the same button (see Rules that refer to something deleted).
  • Auto-Translate and leaving the tab. If you leave Translations while Auto-Translate is running (or a teammate takes over Translations), the run stops: what was already translated stays, and you are told how many fields were not translated so you can run it again.
  • Distribute. Test links and other channels are not locked. An open Distribute tab refreshes its list every few seconds, so a link a teammate adds or renames appears without reloading; if two people rename the same link at once, the last save wins.
  • Conjoint DOE libraries. Generating or uploading a DOE library is not locked either. The DOE Libraries card loads the list each time you open a conjoint's DOE tab and refreshes it quietly every 15 seconds while it stays open, so a library a teammate generates or uploads appears without reloading. The refresh button beside DOE Libraries still reloads it at once.
  • View access stays view access. If you can view a survey but not edit it, the builder opens with a View only banner: you can look around (open and close sections, select a question and read every tab of its Properties), but nothing can be changed. This holds from the moment the builder opens, even when live editing is unavailable on your network. The question palette, Add Section, AI Edit, Undo, Save and Publish are off (hover them to see why), and so are renaming the survey, changing its status, Restore in Version history and adding, renaming or deleting test links (you can still copy and open them). You still see who is editing a question, a section or a tab. If your edit access is taken away while you have the survey open, the builder turns view-only within a few seconds, whether or not you are typing, and the banner tells you how many of your latest changes were not saved. If you are given edit access while you have it open, the builder reconnects within a few seconds and becomes editable, without a reload. A brief HM Admin outage does not take anyone's access away. If your access to the survey is removed altogether (or your account is deactivated, in Survey Builder or in HM Admin), the builder says "You no longer have access to edit this survey" and stops syncing. Being signed out is different: if you sign out in another tab, or your session ends, the builder pauses syncing and keeps the changes it had not sent yet, the You have been signed out notice appears, and once you sign back in as the same person the builder reconnects and sends them. If someone moves the survey to Trash while you have it open, every change accepted until then is saved first (Version history shows Saved automatically when the survey was moved to Trash), and the builder says "This survey was moved to Trash" and turns view-only. Restoring it from Trash brings it back with those changes.
  • Your own other tab. If you have the survey open twice, a question you are editing in the other tab reads "You are editing this in another tab".
  • The sync status next to the save status in the toolbar reads Synced, Syncing…, Offline, Reconnecting… or Preparing… (the survey is being set up for live editing). Offline shows in amber: editing is paused until the connection is back (see Offline below). If live editing cannot connect at all (a company network can block it), the toolbar reads Live editing unavailable instead: Save, autosave, Publish and restoring an earlier version still work, your saves are combined with what others change live, and their changes appear in your builder each time you save. You cannot see your teammates' locks then, so if you changed something a teammate has open, that one change waits for them: everything else is saved, you are told "Name is editing … Your change there is kept here and saves once they finish", and autosave saves it as soon as they move on. Publish waits for it too, and says so, rather than publishing without your change.
  • Opening a survey nobody has had open for a while (about 15 minutes or more) can take a moment before you can edit: from the moment the page appears, the builder's outline shows in grey under Preparing live editing…, and your survey appears in it as soon as everyone is working on the same copy. If you are offline, editing stays paused until you are back online.

When two changes meet#

What happenedWhat you see
You and a teammate changed the same thing at the same momentA message shows both versions. Choose Use mine or Keep theirs. Nobody's change is replaced without you being asked.
A teammate deleted a question or section you had just changed"Deleted by Name" — once for that question or section, however many changes you had made. Undo brings it back with your changes.
You deleted something a teammate had just changed"Name edited this just now" with Undo delete.
Your change reached a question someone else had just started editing"Name is editing Q5". Your change is kept on your screen and applied when they finish; you can Discard it or Copy my text. The message closes by itself once your change has gone in, or once it has become a clash for you to decide.
Your change pointed at something that was deleted (for example logic that jumps to a removed section)A message names what was deleted; the change is not applied.
Someone deleted a question, answer option or global variable that a rule still uses (a display or skip condition, a Branch, a quota, a carry forward, or piped text in a question)The delete goes ahead, and nobody is left unaware: the person who deleted it sees "Q2 is still used" with where it is used (for example "Q9's question text"; for a global variable this includes text that pipes it, ${gv://Field/name}, and a flow element is named by its label), everyone else sees "Name deleted Q2" with the same. The rule stays as it was written and reads Missing question, Missing option or Missing variable where the deleted item was; piped text shows Missing question in the question instead of the code, until someone edits it or the delete is undone.
You piped a question into your text at the moment a teammate deleted itYour text is kept. You see "Q1 was deleted" and the piped part shows Missing question; everyone else sees "Name piped Q1, which was deleted". Pipe another question or remove it.
Two people created the same variable by name at the same moment (for example both turned on ZIP lookup)There is one variable, not two.
Undo would overwrite something a teammate changed after youThat part is skipped, and a message says some changes were not undone because someone else changed them. Undo only ever undoes your own changes.

Saving, publishing and history#

  • Save and autosave record a version of the survey exactly as everyone sees it at that moment, including your teammates' changes. Version history shows who saved each version.
  • Publish publishes the survey as it was when you clicked — changes made after that stay unpublished until the next publish. A publish never goes backwards: if a teammate published a newer state of the survey just before yours went through, theirs stays live (it already includes your changes) and you see Nothing to publish with a note saying so. If the survey had been paused or closed since, your Publish reopens it with their newer publish.
  • Restoring an earlier version is itself a change everyone sees live; only what differs from that version changes, and nothing after it is deleted, so a restore can be undone by restoring again. A question (or tab) a teammate is editing at that moment is not overwritten under them: you are told "Name is editing Q5", and it is restored when they finish — unless they changed it meanwhile, in which case you choose Use mine or Keep theirs. A very large restore (hundreds of changed questions or fields) is sent in parts: what the survey held just before is first saved as a version ("Before restoring v3"), so if a teammate changes part of it meanwhile and that part cannot be applied, you are told part of the restore was saved and can Retry the rest, and nothing is lost either way.
  • One very large field. A single field larger than live editing can send at once (about 512 KB, for example a list of thousands of options pasted into one question) is not saved, and you are told so: add it in smaller parts.
  • Autosave and unfinished work. An unfinished rule (for example skip logic with no target yet) stops the survey from saving until it is finished. Autosave tells only the person working on that question; an explicit Save always tells you why it did not save.
  • After everyone has left. Once nobody has had the builder open for 15 minutes (it was closed, or left in a background browser tab while nobody else was in the survey), anything not yet in a saved version is saved automatically the next time the server checks (Version history shows it as "Saved automatically after everyone left the editor"). On a quiet server that check can come later than the 15 minutes. Opening a survey without changing anything saves nothing: a published or closed survey you only looked at gets no new version, and does not start showing unpublished changes. Nothing is lost meanwhile: every change is already on the server, and if someone opens the builder first, they simply carry on with it. From then on, other tools (HM Admin, an integration) save changes to it the usual way. The next person to open the builder carries on exactly where everyone left off.
  • Offline: editing needs a connection; changes cannot be made offline. If your connection drops, editing pauses at once: the builder becomes read-only under an amber Offline. banner, and Save and Publish say "You're offline. Editing is paused until the connection is back". A change you made just before the drop is still sent when the connection returns. If the connection is back within 30 seconds, editing simply resumes. If it stays down for 30 seconds while the tab is on screen, your edit locks are released, changes that had not reached the server are not kept, and a "You were offline" notice appears: as soon as the connection is back you are taken to the project list (inside HM Admin, its Projects page), the same place Back goes. Time spent in a hidden browser tab does not count. If your network reaches the server but blocks the builder's live connection, Save and autosave save your work the usual way as long as nobody else is editing the survey at that moment, and leaving then asks only about changes made since the last save. When you reconnect, your screen catches up with everything your teammates did meanwhile; a tab reconnecting after being offline never overwrites newer work by saving.
  • Reload builder tabs left open across a release. A tab loaded before live editing was released runs the old builder, and it is the one kind of tab that can still overwrite newer work. While anyone edits the survey live, its Save and autosave are refused (Failed to save project), its Restore in Version history is refused too (Failed to restore version) and changes nothing, and its Publish fails with Failed to publish project and changes nothing, except in two cases. If the tab has no unsaved changes, the version it shows is already published and the survey is not paused, Publish does nothing and says there was nothing new to publish. If the tab has no unsaved changes and the survey's name, description, settings, styling, welcome card and language still match what it loaded (as last saved): then it publishes the version that tab shows, which restores that version over what teammates have edited live since (their content is kept as a Before restoring vN version in Version history). Once nobody has had the survey open in a reloaded builder for about 15 minutes, that tab is no longer refused at all. Its Save and autosave are accepted and replace the draft with what the tab shows, so everything teammates did since the tab was loaded is kept only in Version history. Its Restore is accepted the same way: the restored version replaces the draft, without being published. Its Publish, when the tab has no unsaved changes, still does nothing if the version it shows is already published and the survey is not paused; otherwise it puts back the name, description, settings, styling, welcome card and language the tab shows, then publishes the old version the tab holds: teammates' question edits stay in the draft, but respondents get the survey as it was before live editing until someone publishes again. Reload any builder tab that was open before a release before you type, save or publish in it.

Leaving the survey#

Every change reaches the server within moments of you making it, so you can normally leave the builder at any time and nothing is lost, whether or not you pressed Save. Leaving means any way out: Back, the side menu, Fielding Dashboard or Summary Dashboard, Docs or Sign Out in your account menu, or, inside HM Admin, Home or Projects in the breadcrumb at the top.

  • A change still on its way. If you leave the instant after a change, the builder waits a moment for it to arrive and then takes you where you were going. You see nothing unless it takes longer than that.
  • When something would be lost, you are asked first. If a change has still not arrived (for example because your connection just dropped), or a change of yours waits for a teammate who is editing that question or tab, a message says exactly what: "You're offline. 2 of your changes haven't reached the server." or "1 change waits for Riya, who is editing Q5." Choose Stay to keep working, or Leave anyway to go without those changes. If you leave the message open, the builder takes you where you were going as soon as everything has arrived.
  • A change the server did not accept. If, while you were leaving, a teammate's change clashed with one of yours, the message says so and does not take you away by itself: choose Stay to see the clash and decide which version to keep.
  • Signing out waits the same way: you are signed out once your changes have arrived, or when you choose Leave anyway. Choosing Stay keeps you signed in, with your changes still there.
  • Reloading or closing the tab at such a moment shows your browser's own Leave site? (or Reload site?) question; when nothing would be lost, no question is asked. Inside HM Admin, leave the editor through its breadcrumb (Home or Projects): it waits for your changes in the same way, which HM Admin's own menu cannot always do.
  • Nothing is kept in the browser. If the page goes away with changes that could not be sent (you closed the tab past your browser's question, or HM Admin's own menu took you elsewhere while a change of yours was waiting for a teammate), those changes are lost; they are not offered back the next time you open the survey. That is why the builder asks first whenever it can.

Without live editing#

Live editing is normally always on. If it has been switched off — something your administrator does only in an emergency — open builders share the whole survey with each other after each change, and saving writes the whole survey.

Warning: Avoid editing the same question at the same time as a teammate. Edits made at the same moment can replace each other. Agree who works on which section, and save often.


Version history#

Every save (manual, autosave, or the automatic save after everyone has left the builder) creates a restorable version. Open Version history from the builder toolbar to compare or restore an earlier state.

If an integration publishes an older version of a survey while it is being edited live (someone has it open in the builder, or had it open recently: a survey stays in live editing for about 15 minutes after the last person leaves, longer on a quiet server), that version is restored first, the same way Restore works: everyone who has it open sees its content appear, and Version history shows Before restoring vN (what the survey held, when no version had it yet) and Restored from vN (the version that was published).


Creator on survey cards#

Survey cards show the creator name so collaborators know who owns the project.


Was this page helpful?