We’ve enhanced the experience of onboarding new vendor users by allowing users with a matching email address domain to automatically join your team. It’s no longer necessary to send invites to each user within your organization if you want to allow read-only access to all employees for that specific team.
If a vendor has multiple teams and wants them all to be joinable by anyone in the company, we give the new user a choice which team to join. If the vendor also has a team they want to keep private, possibly separating a production team from a dev team, they can keep auto-join disabled for the private team, and people will only be able to join if explicitly invited. If a user is eligible to accept an invite or auto-join a team, they’ll get all of those choices, and accepting the invite is assumed to be the preferred action.
A team’s security constraints, such as requiring Google Auth to login, or more complex password requirements are still enforced when the new user joins.
By default, this feature is opt-in since some information in the vendor portal, like your release history or customer list, may be sensitive and your organization may not want your entire company to have access. This feature can only be configured by users who have the appropriate privilege based on their RBAC policy (Admin only by default).
To enable this setting, you’ll need to first log in to the vendor portal. Once logged in, you can access your team’ settings in the top right:
Next, navigate to the ‘Auto-join’ page from the left-hand navigation bar:
Vendor portal uses your current session to determine the email domain or Google Workspace account that will be linked to your team. Once you’re on the ‘Auto-join’ page, you can choose to enable this feature:
When new users register on the vendor portal, they’ll now be prompted only to provide their company email address, or continue with Google Auth.
If they enter in an email address, they then will have to check their emails for their activation code and either enter it directly onto the following page, or click on the link which will fill it in for them.
If the user continues with Google authentication, they won’t need to jump through the email verification step.
Either way, the vendor portal will check to see if there are matching teams that have auto-join enabled and if the user’s email address has any pending invites. If a user is explicitly invited to a team that is also available for auto-join, the invite takes precedence and the auto-join choice is hidden to avoid confusion. This helps when the default auto-join RBAC role has less permissions than the invite. The user will then be provided a choice to either join one of the teams they were invited to, join one of the teams that are eligible to auto-join, or create a new team. Below is an example of this page where the user can accept an invite, auto-join a team, or create a new team. The page will be skipped if there are no teams available to join.
Or if there are two auto-join enabled teams:
Clicking on one of the teams to join will then present the user with a screen to finish creating their account and accept the invite.
If instead the user clicks to Create a new team, they’ll see a form asking for details for the team.
There are a few things to consider before enabling Auto-join for your team. It is important to consider your account tier with Replicated. All vendor teams have access to the built-in ‘Read Only’ policy used by default for this feature as well as an additional ‘Admin’ account. Business Tier customers have access to 2 additional built-in roles for Support and Sales. This feature can only be enabled by users with permissions to "team/authentication/*.” By default, this is accessible to the built-in ‘Admin’ role and may be configured for other roles for enterprise tier teams. Enterprise Tier customers have all of these roles as well as the ability to create additional custom RBAC policies. For more details on RBAC policies in vendor portal, review the documentation here.
When enabled, any user that has validated their ownership of an email address from your team’s domain can automatically join the team. When they join, their account in your team will be assigned the RBAC policy that is configured for this feature. By default, this is set to the built-in ‘Read Only’ policy, however any user with the appropriate privilege can change this default policy for users joining the team via this method. If your team also has Google authentication enabled, then this will also apply when a new user is logging in via Google authentication too. If your team isn’t already using Google Authentication, then you can turn this option on.
The single exception to the above is for users who are invited to the team. Normally, users will join the team via the invite link they receive in their email. If the user ignores this email and, instead, registers for an account on vendor portal, they will see the existing invite. If the user chooses to join the team that has invited them, then the RBAC policy applied to the invite will apply to the new user’s account. For details on inviting team members to your team, review our documentation here.
Lastly, the option to join a team is not provided for users signing in with SAML, and auto-join can not be enabled at all if the team enforces SAML authentication. This is because as a team that enforces SAML authentication, new users must authenticate via the SAML provider’s application dashboard and must be given access to the team through their identity provider.
If a user clicks to join a team, but doesn’t finish the account creation process, there will be a hidden invite created for them. If they then go in to start the signup process again, they’ll see that existing invite and be able to finish the process. There just might be some confusion because it will show up as an invite they can “accept” rather than a team they can “join”
As we continue to roll out more Insight features, you can expect more people within your organization to want access to the vendor portal to see metrics. Auto-join is a great way to allow that, so if your security model allows it, look at enabling it today!