Understanding how end-users, invites, and publishing fit together

NOTE: Unless a person is designated as a project owner, they will not have access to the V|V within that project. Once the V|V is published, people who are designated as stakeholders, participants, or viewers for the project will be able to access the V|V.

A project has a list of people associated with it. Some of these people are project owners who are the folks that upload content and create V|Vs. The other people are end-users, people who consume and interact with V|Vs once they are ready to be shared. Over the life of a project, you may find that you want to change who has access to different V|Vs. At the beginning, you might want to restrict access to just a few high-level stakeholders at an organization. As the project evolves and gains clarity, you might want to share with a broader list of people. Rather than having to change the list of people associated with a project, we instead give you the ability to build up a master list of people that will typically grow over the lifespan of a project. You can then tweak permissions for individual people within that master people list as the project progresses. There are several ways to tune these permissions. Generally, you can adjust which end-users are invited to which particular V|Vs right before they are published and you can change the roles individual end-users have over time. Here's an example lifespan for a particular end-user:

  1. As a project gets started, a small set of people are initially invited to join the Visual Vocal system as viewers. Their feedback isn't yet being solicited but you want to keep them apprised of early stage progress.
  2. Right before you publish your first V|V you determine that some of those people are not yet relevant to the discussion so you turn off their invites for the soon to be published V|V. Those people who you uninvite are still members of the project but they will not receive an invite to the V|V when it's published. End-users who are invited will get an email invitation to the V|V shortly after you publish the V|V.
  3. For your second V|V, as alternative design choices become available, you decide to both add new people to the project and to invite some of the existing end-users to the new V|V. Inviting people to the project would happen at the project level, along with setting their initial role (project owner, stakeholder, participant, or viewer). Existing end-users, who have previously not been invited to published V|Vs, can receive invitations if you change their invite status within the context of a V|Vs invites.
  4. Based on how the project progresses, you may decide that some of the end-users who were previously only granted viewer access, should now be invited to give more substantial feedback. In this case you would change their roles from viewer to either participant or stakeholder and make sure that they are included in the invite list for the next to be published V|V.
  5. As a project nears completion, you may decide to apprise a much broader set of people with what will be coming to fruition. For this scenario, you would add the new end-users as viewers, before final-stage V|Vs are published and make sure they are on the invite list for the V|V.
  6. Upon completion of the project, the project owner or organization admin can choose to archive the project. This will also archive all associated content.


More information and step-by-steps:

To see how to accomplish the various user management tasks, refer to these articles:

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Please sign in to leave a comment.