Product documentation
Citrix SecurSpaces™
View PDF

Onboard developers

August 19, 2026

Project Owner

Onboarding someone into a project is one decision followed by a short task. The decision is whether they create their own workspaces or you create one for them. Everything else follows from that.

This page is written for the person doing the onboarding. For what the developer does once they are in, see Get started.

Two ways to onboard someone

The difference is the Workspaces permission carried by the role you assign.

  Self-served Assigned
Role Developer, Manager, or Project Owner Guest
Workspaces permission Manage Personal or higher Access
Who creates the workspace The developer, from your template You, before they arrive
Can they change it Yes — settings and resource access No — the configuration is fixed
Suits Employees and long-term team members Contractors, external collaborators, anyone temporary
Your effort Set up a template once One workspace per person

Self-served is the normal case. Choose assigned when you need the environment to be exactly what you decided and to stay that way, which is usually about limiting what an outsider can reach.

Both models can coexist in one project. The role is per person, so you can have ten self-served developers and two contractors on fixed workspaces.

Before you onboard anyone

Have the project ready first, or your first developer arrives to an empty environment. See Set up a project for your team, which covers images, repositories, secrets, and the template both models depend on.

You need the Members permission set to Manage to add people. The default Manager and Project Owner roles both carry it.

Onboard a self-served developer

  1. Open People and select Add New User.
  2. Find the user, and leave the role as Developer, or choose Manager or Project Owner if they will run part of the project.
  3. Select Apply.

They can now create their own workspace from your template. Nothing else is required from you.

Onboard a guest or contractor

  1. Open People and select Add New User.
  2. Find the user and set the role to Guest.
  3. Select Create a new workspace from a template or an existing one, and choose the template that matches the work.
  4. Select Set Expiration date and choose when their access ends.
  5. Select Apply.

The workspace is provisioned as part of adding them, so there is no separate assignment step. When they sign in, the workspace is waiting and its settings are fixed.

Set the expiration date even when you expect the engagement to be extended. An expiry that has to be renewed deliberately is safer than access that quietly persists after someone has moved on.

See Add and remove users for the full dialog, including inviting someone who is not on the platform yet.

What the platform sends for you

Adding a user to a project triggers a You’ve joined a new project email containing a link straight into the project. Someone new to the platform entirely also receives an invitation email.

This only works if a platform administrator has configured an email gateway. Until one is configured, the platform sends nothing at all, and your new developer is waiting for a message that will never arrive. If you are not sure, check with your platform administrator before you rely on it, or tell people directly that they have been added.

See Onboarding email notifications.

What the developer does next

Point them at Get started. A self-served developer wants Your first workspace; a guest already has one, so Set up your account is the better starting point.

If you would rather hand over something written for your own team, adapt the reusable onboarding template, which you can fill in with your repositories, tools, and policies.

Onboard developers
August 19, 2026
August 19, 2026

In this article

Site feedback | Your privacy choices footer linkYour Privacy Choices | Privacy and legal terms | Cookie preferences | Consent settings | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.