Deployment Access Groups

Once your experience is created, and it is time to deploy; the GMetri platform offers a wide range of authentication mechanisms that ensure that your target audience can view those experiences with ease while also maintaining security.

As an organization, one of the most common use cases for a deployment is to limit or allow access to certain groups of people.

To address this issue, we will look at Deployment Access Groups (DAG). A Deployment Access Group is a list that can allow access to a deployment via certain authentication mechanisms.


Getting Started

To create a Deployment Access Group, head over to the settings page (to access the settings page, see the image below)

Settings page

NOTE: Only Organization admins can create DAGs, if are not an admin, please ask you organization's admin to create these for you

On the settings page, click on + Access Group under the Deployment Access Groups section. This will create a new Access Group for your organization.

If you followed the steps, you will see a new Access Group as shown here

Deployment Created

Access Group options

Once your Access Group is created, it will be assigned a randomly generated name, you can rename it as per your requirement or continue with the same name.

We are going to use this access group to allow only specific people to access our deployment and make sure that the they use the google sign in. So we will rename our Access group to Google with access list. If you wish to follow along, you can rename it so now.

Now, click on the little arrow to open up your access group to reveal the customization options.

the opened access group

By default, the editor option has been selected, this allows only the portal editors to login in and view your experiences. Lets select the Google Private option to set the login method to google.

the list of options available

Once you have selected Google Private you will be presented with the following:

File selection option

Now, if you try and click on save, the page will show you an error saying File not uploaded. This is because, we have selected the Google Private option, which requries us to provide our access group with a list of accepted emails

To upload a list of allowed emails, we will create a simple google sheet and upload it here. Lets do that now, to start off, let us download a sample google sheet from the link below

Link to sample CSV for specifying allowed users

In the sample file, let us remove the password column since we want our experience viewers to use their Gmail accounts to login.

Now, go ahead and add some Google Mail IDs to the email column. Save this file as a .csv and upload it here. Once you upload, click on Add to upload the file.

File selection option

And then finally save the changes made to the access group by clicking on SAVE.

File selection option

This creates your access group which you can now use on your deployments. To use this Access group, simply go to any one of your projects, then select any deployment for which you want to use this access group.

File selection option

NOTE: To use the access groups, you have to make a deployment private, ie, by setting the public swtich to OFF as shown in the image.

Once you select it, the login methods will come into effect when people are viewing are your experiences. With this we finish our mini tutorial of how to create a Access Group. Happy creating!


Login Methods

A deployment access group is used to set the login options on a deployment when the its visibility is set to private off (ie, in the deployment, you set the public switch to OFF)

The Deployment access group provides 5 major options:


This option allows anyone with a valid Google ID to login.

Google Private

This option allows only whitelisted google email IDs to use Google ID to login.

NOTE: please see the adding whitelists section section below for more information on how to create whitelists


This option allows anyone with a valid Azure ID to login.

Azure Private

This option allows only whitelisted azure email IDs to use Azure ID to login.

NOTE: please see the adding whitelists section section below for more information on how to create whitelists


This option allows to generate automatic login tokens to login the viewers. A great way to use this feature is to autogenrate the login tokens via an API and create limited time login links.


Sometimes you may need a custom login form that requires a login identifier other than an email (eg, phone numbers, special usernames, etc). In such cases, you can simply rename the columns to the desired name and it will show up in the login form.

The second column in the csv is treated as the password field (regardless of what you reaname it to). If it is present the csv, we will authenticate all your users against the provided passwords. If you wish to skip password verification, please remove this column from the csv.

A sample CSV containing some users with their names and an arbitrary password will look like:

Sample userlist with passwords

A sample CSV containing some users with only their names and no password will look like:

Sample userlist with passwords

NOTE: Once the csv has been uploaded , you cannot see the passwords again (for security purposes), so if you wish to change the password of some or all your allowed users, please upload a new csv with the updated passwords.

This option allows only whitelisted IDs along with an optional password to login.

please see the adding whitelists section below for more information on how to create whitelists


This option allows only the members of the organization to login via their gmetri portal accounts. This is great way to test out an experience internally before releasing it to your intended audience.

Adding whitelists

In an access group, certain options allow you to specify a whitelist. This is a csv file containing the lists of the users who allowed to access the experience.

To start off, download the sample csv.

In this csv, you can specify the emails that will be allowed to view the experince.

NOTE: When using options like Azure and google private lists, make sure that these emails are of the correct domain and also make sure that you do not include the password column, otherwise your users may not be able to view the experiences.

Last update: