Skip to main content

Sharing

Sharing controls who can see and edit a project in the online environment. The desktop client does not support sharing — it is single-user by design. Sharing in Siter is token-based: an Admin generates a share token, the recipient submits a request using the token, and the Admin accepts the request with a chosen role. For the click-by-click flow, see Sharing projects.

Learning objectives

By the end of this lesson you should be able to:

  • Generate a share token and send it to a collaborator
  • Pick the appropriate role when accepting an access request
  • Recognize the difference between the four project roles
  • Stop sharing or revoke an existing token

The four project roles​

When accepting an access request, an Admin picks one of four roles for the requesting user:

RoleWhat it allows
Read OnlyView features, results, drawings, and forms; cannot run analysis or modify anything
Read and WriteEdit features, run analysis, modify result sets, generate drawings and forms
Just AdministratorManage sharing and access requests, but does not have edit rights to the project's features
Full AdministratorCombination of Read and Write + Administrator — edit rights and sharing-management

Roles are project-scoped: the same user can be Read Only in one project, Read and Write in another, and Full Administrator in a third. There is no global role.

note

Sharing is online-only. The desktop client does not synchronize between machines and does not support multi-user collaboration.

How sharing works​

Sharing is a three-step flow, not a direct invite:

  1. Generate a token on the project's Sharing tab. Siter produces a short share-token string with an expiration date.
  2. Send the token to the collaborator out-of-band (email, chat, etc.). They use it to submit an access request from their own Siter account.
  3. Review the request on the project's Sharing tab. Pending requests appear in a queue with Status, User Name, Organization, Email, and Submitted Time. Accept (with a role of your choosing) or reject.

The token is reusable — multiple collaborators can submit requests using the same token until it expires. Each request requires its own accept/reject decision.

Stopping or revoking sharing​

The Sharing tab carries a Stop Sharing action that invalidates the active token. New requests can no longer be submitted with it. Existing accepted users keep their access until removed explicitly through their entry on the Users tab. If the token has expired naturally, a Share It Again button appears to mint a new one.

When sharing does not survive​

A few operations break sharing:

  • Importing a project from a snapshot — sharing is not preserved on import. The imported project starts with no shares; the importer must reassign permissions explicitly. See Export and import.
  • Copying a project — the copy is private to the user who created it; collaborators on the source do not automatically get access to the copy.
  • Archiving a project — does not remove shares, but archived projects are hidden from the My Projects view for shared users until restored.

Try it​

In an online project where you have an Admin role:

  1. Open the project dashboard's Sharing tab and click Share It to generate a token
  2. Note the token's expiration date
  3. Have a colleague submit an access request using that token
  4. Accept the request at Read Only and confirm the colleague can open the project but cannot run analysis
  5. Remove their access (via the Users tab) and confirm the project disappears from their My Projects list