About policies¶
A policy represents a set of actions that are available to a user when that policy is assigned to them.
This section describes the policies that are available in Amperity and that may be assigned to users, along with the actions that each policy represents. You may assign more than one policy to a user.
Important
If you see the message “Access Denied” when trying to access a page in Amperity, you may not have sufficient policies assigned to your user. See the list of actions by policy for detailed information about the specific areas within Amperity that each policy represents.
How policies work¶
Actions within Amperity are controlled by policies, which act as containers for a set of actions. All tenants share a set of global policies with groups for standard policies and administrator policies. Each tenant assigns one (or more) policies to every user in their tenant, after which each user may also be assigned any of the policy options.
Each user has a set of assigned actions that are determined by their assigned policy (or policies). Policy assignment may be managed using SSO (recommended) or may be managed from the Amperity user interface by users who are assigned the User Administrator policy option.
The access model in Amperity defines actions as short strings that contain a resource type and an associated verb. A policy is a series of statements that allow or deny actions. For example: pii:download is an action. pii is the resource type and download is the associated verb. A user that is authorized to perform this action may run a query or segment, and then click the Download button to download the results.
When a user logs on to Amperity the policy (or policies) that are assigned to that user are identified, and are then used to determine the set of statements that allow or deny actions to that user.
Amperity reviews all statements to determine if a user is allowed to perform an action. A user action is allowed when a statement allows the action. A user action is denied when a statement denies the action or when no statements match the action.
Example
The following individuals comprise the Amperity team at ACME Corp: Ace Managhan (a SQL expert), Amanda Heller (the main point of contact for source and destination configuration), along with two members of the marketing team (Paul Jackson and Kendra Hallett).
Ace and Kendra are assigned the DataGrid Operator policy in their production tenant and are assigned the DataGrid Administrator policy in sandboxes. Ace works closely with Paul and Kendra to support their downstream marketing activity. Amanda works closely with Aaron Beck, who is their Amperity representative and also their Sandbox Administrator. Aaron reviews changes to ensure that updates to production go smoothly.
Paul and Kendra belong to the marketing team. Paul is assigned the AmpIQ User policy and manages all campaign sends from HubSpot and Klaviyo. ACME Corp policy requires that only certain members of the company can have access to customer’s profile data, which Kendra requires, but Paul does not. Paul is restricted from viewing profile data (though he can see the email addresses within HubSpot and Klaviyo, but only after they are sent from Amperity) and cannot download the segment results.
Kendra manages a complex series of marketing campaign activity through Salesforce, some of which requires verification of certain types of profile data before sending it to Salesforce from Amperity. Kendra often uses SQL to build custom queries to return specific results for key downstream use cases.
Paul and Kendra work closely with Amanda to make sure the right data is being sent to their downstream marketing activities and also work closely with Ace to ensure they have access to the right sets of tables when building segments and queries.
Standard policies¶
The following standard policies are available:
Amp360 User¶
The Amp360 User policy allows full access to the Queries tabs, the ability to run orchestrations from the Destinations tab, and read access to the Customer 360, Stitch and Workflows tabs.
Assign this policy to users who will manage databases, manage SQL queries, and send the results of queries to pre-configured destinations.
AmpIQ User¶
The AmpIQ User policy allows full access to the Metrics, Segments, and Campaigns tabs.
Assign this policy to users who will explore metrics, manage segments, explore segment insights, build and run campaigns, and review campaign results.
DataGrid Operator¶
The DataGrid Operator policy allows full access to Amperity, including the Sources, Stitch, Customer 360, Queries, Segments, Campaigns, Destinations, and Workflow tabs.
Assign this policy to users who will manage data sources (including feeds, couriers, domain tables, and schedules), manage destinations (including templates, orchestrations, and credentials), along with any of the actions allowed by the Amp360 User and AmpIQ User policies. A DataGrid Operator has visibility into all resource groups.
Tip
Assign the DataGrid Operator policy to DataGrid operators for all work done within your production tenant. Assign the DataGrid Administrator policy to the same users within a sandbox.
This ensures that configuration changes can be made within the sandbox, including being able to access and run all workflows that are required to validate those changes. When the configuration changes are ready they can be pushed to your production tenant.
Administrator policies¶
The following administrator policies are available:
API Key Administrator¶
The API Key Administrator policy allows full access to managing the API keys and access tokens that are used with the Profile and Streaming Ingest APIs. This policy enables the API keys list on the Users and Activity page.
DataGrid Administrator¶
The DataGrid Administrator policy allows full access to Amperity, including any of the actions allowed by the DataGrid Operator policy, along with the ability to use a sandbox to make changes to sources, Stitch configuration, databases, and destinations, but without the ability to push changes in that sandbox to production.
Assign this policy to users who will make configuration changes using a sandbox, after which those changes will be reviewed by a user assigned the Sandbox Administrator policy. A DataGrid Administrator has visibility into all resource groups.
Tip
Assign the DataGrid Operator policy to DataGrid operators for all work done within your production tenant. Assign the DataGrid Administrator policy to the same users within a sandbox.
This ensures that configuration changes can be made within the sandbox, including being able to access and run all workflows that are required to validate those changes. When the configuration changes are ready they can be pushed to your production tenant.
Profile API Administrator¶
The Profile API Administrator policy allows full access to the Profile API section on the Destinations page. This policy enables the Profile API list of endpoints on the Destinations page.
Read-only options¶
The following policies have read-only options:
Note
Allowed read-only actions are indicated in the policy table using the icon.
Amp360 User - Read Only¶
The Amp360 User - Read Only policy allows read-only access to the Customer 360 and Queries tabs.
Assign this policy to users who will explore databases and SQL queries, but will not create queries or send the results of queries to configured destinations.
AmpIQ User - Read Only¶
The AmpIQ User - Read Only policy allows read-only access to the Metrics, Segments, and Campaigns tabs.
Assign this policy to users who will view and explore metrics, segments, and campaigns, but will not create segments or run campaigns.
DataGrid Operator - Read Only¶
The DataGrid Operator - Read Only policy allows read-only access to the Sources, Stitch, Customer 360, Queries, Metrics, Segments, Campaigns, and Destinations tabs.
Assign this policy to users who need to view the entire application, including all resource groups, but should not make changes.
Policy options¶
The following policy options are available:
Note
Restricted actions are indicated in the policy table using the icon. Any user may be assigned the User Administrator policy option (indicated by ).
Restrict Data Export¶
The Restrict Data Export policy option prevents users from using orchestrations or campaigns.
Restrict Download Access¶
The Restrict Download Access policy option prevents users from downloading query and segment results.
Restrict PII Access¶
The Restrict PII Access policy option prevents users from viewing data that is marked as PII anywhere in Amperity.
Restrict Upload Access¶
The Restrict Upload Access policy option prevents users from uploading files to the Customer 360, Queries, or Segments pages.
User Administrator¶
The User Administrator policy option allows users to manage users and resource groups.
All of the users and all of their associated activity can be viewed and managed from a single page in the Amperity admin user interface. User access to Amperity is managed in two steps:
Authentication determines and validates who the user is.
Authorization determines what that user is allowed to do.
An unauthorized user may not access Amperity; an authorized user may only view and interact with the areas within Amperity to which their policy allows access.
Manage users¶
The Users section of the Users & Activity page allows users who are assigned to the User Administrator policy option to self-service the management of individual users who have access to your tenant.
Important
Please contact Amperity Support if you have lost access to your User Administrator account.
Add users¶
Before a user can log into Amperity they must be added and a policy must be assigned to them. The Amperity admin interface allows users to be managed directly using name and password authentication.
To add a user
From the ellipses menu in the top right, click Users & Activity.
Under Users click Add User. The Create User dialog box opens.
Enter the user’s full name (e.g. “Justin Currie”) and the email address with which they will log into Amperity (e.g. “justin.currie@amperity.com”). Only users from a known domain are allowed to access Amperity.
Select the standard policy to which this user will be assigned.
Select a resource group to which this user will be assigned.
Be sure to send the user a welcome to Amperity email. (This is enabled by default.)
Click Save.
Delete users¶
All users who should no longer be allowed access to Amperity should be deleted. This will delete the user for all tenants to which that user is assigned. Use the revoke tenant access process to delete a user from a tenant when that user has access to more than one tenant.
To delete a user
From the ellipses menu in the top right, click Users & Activity.
Under Users, from the list of users, select the ellipses menu, and then click Delete.
Edit users¶
If the details for a user change, such as changing the policy to which they are associated, their details may be updated.
To edit a user
From the ellipses menu in the top right, click Users & Activity.
Under Users, from the list of users, select the ellipses menu, and then click Edit. The Edit User dialog box opens.
Make your changes.
Click Save.
Revoke tenant access¶
Amperity users may have access to more than one tenant in Amperity. For example when two brands are managed as separate tenants. If a user has access to more than one set of data, access to an individual tenant may be revoked, which will prevent the user from being able to access this tenant. Access to any other tenant to which that user is assigned remains unchanged.
To revoke tenant access
From the ellipses menu in the top right, click Users & Activity.
Under Users, from the list of users, select the ellipses menu, and then click Revoke tenant access.
Allowlist domains¶
Only users from a known domain are allowed to access Amperity. Amperity maintains a list of approved domains for all users. This acts as an additional step to verify that all users are approved users. Any user that is created with an unknown domain will be automatically denied.
To allowlist a domain
From the ellipses menu in the top right, click Users & Activity.
Under Users click Add User. The Create User dialog box opens.
Under the Email box, click the Domain link. The Request to Allowlist a Domain dialog box opens.
Add the domain for which the request is being made, and then specify the reason why it should be allowlisted.
Click Send.
Manage resource groups¶
A resource group represents one or more databases in the Customer 360 tab. Users with access to a resource group can build queries and segments against that database and can send data from that database to downstream workflows.
“All resource groups”¶
Amperity includes one default resource group: “All resource groups”.
Users that are granted access to the “All resource groups” resource group are allowed to interact with all of the databases in the Customer 360 tab.
Custom resource groups¶
Use a custom resource group to support any combination of team member access to brand-specific databases.
Note
Users who are associated with a custom resource group cannot access the Sources tab. (The Sources tab requires users to be able to access all data available to the tenant.)
Users who are associated with a custom resource group may be able to view the Stitch tab (depending on their policy), but will not be able to view personally identifiable information (PII).
To add a custom resource group
As a user with Admin privileges, from the ellipses menu in the top right, click Users & Activity.
Next to Resource Groups, click Add Resource Group.
Enter the name of the custom resource group and a description.
Click Save.
Assign users to resource groups¶
Assign a user to a policy, and then associate that policy to a resource group. A user may be assigned to more than one policy. A policy may be associated with any resource group.
Assign users to policies and resource groups when they are added to Amperity. This can be done using the Amperity UI or from your identity provider (IdP) when managing users with SSO group mappings.
Database permissions¶
A database may be associated with a single custom resource group. A custom resource group may be associated with more than one database.
Note
A database is always associated with the “All resource groups” resource group.
A database that is assigned permission to a custom resource group allows users associated with that resource group to:
View that database from the Customer 360 tab.
View all tables in that database.
Configure database exports from that database.
Build segments and queries that run against that database.
Design campaigns that send the results of segments to downstream workflows.
Use destinations to send the results of queries to downstream workflows.
Note
Users who are associated with the “All resource groups” resource group are allowed to add and edit databases in the Customer 360 tab and run Spark SQL queries against all of the data in the tenant.
To set database permissions for a custom resource group
From the Customer 360 tab, under All Databases, click the ellipses menu for a database, and then click Change Permissions. This opens the Permissions dialog box.
Click Standard Access, and then select a custom resource group from the drop-down list.
Click Save.
Multi-brand tenants¶
Use a combination of custom resource groups to define how teams in your organization can interact with brand databases in Amperity, where each custom resource represents a brand.
For example, a tenant with multiple brands, a global analytics team, multiple brand-specific teams, and multiple databases can:
Configure a policy for the global analytics team and assign the policy to the “All resource groups” resource group.
Define a custom resource group for the owners of brand A, and then configure these owners with a policy that is assigned to the brand A resource group.
Define a custom resource group for the owners of brand B, and then configure these owners with a policy that is assigned to the brand B resource group.
Configure the database for brand A for permissions to the custom resource group associated with brand A.
Configure the database for brand B for permissions to the custom resource group associated with brand B.
This will allow members of the global analytics team to access the databases for brands A and B while ensuring that brand owners can only access their brand’s database.
Review user activity¶
Amperity keeps a record of all user activity. The activity list displays the following columns:
Date The date and time of the action (displayed in your local time-zone).
User The user who took the action. For most users, this is that user’s friendly name or email address. An auth token is displayed for users that accesses Amperity programatically.
Action The action taken in the application. Generally this will take the form of “action type/action”. For example, activating a segment appears as “segment/activate” and running a segment for download appears as “query.exec/download”.
Note
A few actions in the list are not user-triggered. For example, when a user is granted a new authorization policy, both the grant and the receipt appear on separate rows, so the recipient appears as an attributed action that was triggered by the grantor.
Object The object against which the action occurred.
For example, if a user ran a segment, that segment’s name is displayed. If a user sent a segment to a destination, both the name of the segment and the destination name will be displayed. If the user was the recipient of a new authorization policy, the policy name will be displayed.
This list can be expanded to display a larger set of data by clicking Show More button at the bottom of the list. Click any header to sort by column.
Download activity¶
All activity may be downloaded to a CSV file. The first row of the user activity file contains the following column headers, and then a row for each tracked event:
column name |
Description |
|---|---|
event-id |
The Amperity internal identifier for the event. This can be used to request additional information about the event, if needed. |
event-type |
Appears in the activity list as the Action column. |
happened-at |
The time the user triggered the action. Appears in the activity list as the Date column. Note The downloaded date and time are in GMT, where the UI displays the same information in the local timezone. |
recorded-at |
The time at which the system recorded the action. May be slightly different than happened-at time due to the asynchronous nature of Amperity. |
principal-id |
The identifier of the user who triggered the action, where user be an API key or other non-human user. This does not appear directly in the activity list. |
principal-name |
The friendly name of the user, if available, otherwise the email address or API key. Appears in the activity list as the User column. |
principal-email |
The email address of the user. May be NULL when the user is an API key. |
external-id |
Internal value only; always NULL in downloaded log files. |
source |
The component within Amperity that added the log entry. This is not always the component that triggered the action itself. |
object |
The identifier for the object for which the action occurred. |
object-name |
A composed string that describes the object(s) for which the action occurred. Appears in the activity list as the Object column. |
origin-ip |
The IP address of the user who triggered the event. |
To download all user activity
From the ellipses menu in the top right, click Users & Activity.
Under Activity click Download.
A CSV file named events-yyyy-mm-dd-timestamp.csv is downloaded.
Copy IDs¶
Individual event, user, and object IDs may be copied.
To copy activity IDs
From the ellipses menu in the top right, click Users & Activity.
Under Activity, from the row for which you want to copy IDs, select the ellipses menu, and then click Copy Event ID, Copy Object ID, or Copy User ID.
Allowed actions¶
The following sections describe the set of actions that may be assigned to users of Amperity. These actions are grouped by page (Sources, Stitch, Customer 360, Queries, Segments, Campaigns, Destinations, Workflows, Users & Activity, and Credentials) with additional sections for the Data Explorer and Sandboxes.
Allowed, optional, and required actions
The following sections use icons to indicate when actions are available.
Allowed. |
A user assigned to this policy can perform this action. |
|
Read-only. |
A user assigned to this policy has read-only access. |
|
Optional. |
This action may be restricted using the Restrict Download Access add-on policy. |
|
Optional. |
This action may be restricted using the Restrict Upload Access add-on policy. |
|
Optional. |
This action is allowed, but visibility of data may be restricted using the Restrict PII Access add-on policy. |
|
Optional. |
This action is allowed when a user is assigned the User Administration add-on policy. |
|
Validation required. |
This action is allowed after changes in a sandbox have passed validation and are ready to be promoted to your production tenant. Note A user should be assigned to the DataGrid Administrator policy while working in a sandbox. |
Sources¶
The following table lists the actions that are enabled within the Sources page when users are assigned to specific policies.
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
View Sources page |
||||
Run validations |
||||
View data lineage |
||||
View semantics |
||||
COURIER GROUPS |
||||
Add courier group |
||||
Delete courier group |
||||
Edit courier group |
||||
Run courier group |
||||
Schedule courier group |
||||
View courier groups |
||||
COURIERS |
||||
Add credential |
||||
Add courier |
||||
Delete courier |
||||
Edit courier |
||||
Run courier |
||||
View couriers |
||||
View credentials |
||||
DOMAIN TABLES |
||||
Add custom domain table |
||||
Delete custom domain table |
||||
Delete domain tables |
||||
Edit custom domain table |
||||
Make available to Stitch |
||||
Publish to Queries page |
||||
View custom domain tables |
||||
View domain tables |
||||
FEEDS |
||||
Add feed |
||||
Delete feed |
||||
Edit feed |
||||
Load new data |
||||
Make available to Stitch |
||||
View feeds |
||||
INGEST SQL |
||||
Add ingest query |
||||
Delete ingest query |
||||
Edit ingest query |
||||
View ingest queries |
||||
NOTIFICATIONS |
||||
View detailed errors |
||||
View notifications |
||||
WORKFLOWS |
||||
Run workflow actions |
||||
View workflows |
Stitch¶
The following table shows which policies enable user actions within the Stitch page.
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
View Stitch page |
||||
Open Data Explorer |
||||
STITCH |
||||
Configure Stitch settings |
||||
Explore Amperity IDs |
||||
Run Stitch |
||||
Select previous Stitch runs |
||||
View semantics |
||||
View Stitch metrics |
||||
View Stitch Report |
||||
NOTIFICATIONS |
||||
View detailed errors |
||||
View notifications |
Customer 360¶
The following table shows which policies enable user actions within the Customer 360 page.
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
View Customer 360 page |
||||
Enable AmpIQ |
||||
Open Data Explorer |
||||
DATABASE EDITOR |
||||
Activate databases |
||||
Activate tables |
||||
Add tables |
||||
Configure database settings |
||||
Delete tables |
||||
Edit tables |
||||
Set as “Customer 360” |
||||
Use SQL editor |
||||
View databases and tables |
||||
DATABASES |
||||
Add databases |
||||
Delete databases |
||||
Delete uploaded file |
||||
Edit databases |
||||
Review validation reports |
||||
Run databases |
||||
Upload file |
||||
View data lineage |
||||
View databases and tables |
||||
DATA EXPORTS |
||||
Activate data export |
||||
Add data export |
||||
Delete data export |
||||
Edit data export |
||||
Select tables for data export |
||||
View data exports |
||||
NOTIFICATIONS |
||||
View detailed errors |
||||
View notifications |
Queries¶
The following table shows which policies enable user actions within the Queries page.
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
View Queries page |
||||
QUERIES |
||||
Add query |
||||
Delete query |
||||
Download query results |
||||
Edit query |
||||
Manage folders |
||||
Search queries |
||||
View all queries |
||||
View large output queries |
||||
QUERY EDITOR |
||||
Access AI Assistant |
||||
Activate query |
||||
Add to orchestration |
||||
Build query |
||||
Copy query results to clipboard |
||||
Delete uploaded file |
||||
Download query results |
||||
Enable materialization |
||||
Enable performance mode |
||||
Enable query alerts |
||||
Make available to AmpIQ |
||||
Open Data Explorer |
||||
Open SQL Query Editor |
||||
Open visual Query Editor |
||||
Run query |
||||
Select database |
||||
Upload file |
||||
Use Spark SQL |
||||
View orchestrations |
||||
View query results |
||||
View tables |
||||
NOTIFICATIONS |
||||
View detailed errors |
||||
View notifications |
Segments¶
The following table shows which policies enable user actions within the Segments page.
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
View Segments page |
||||
SEGMENTS |
||||
Add segment |
||||
Delete segment |
||||
Download segment results |
||||
Explore segment |
||||
Explore customer records |
||||
Manage folders |
||||
Open visual Segment Editor |
||||
Open SQL Segment Editor |
||||
Save segment as … |
||||
Search segments |
||||
Set segment charts |
||||
View segments |
||||
View segment insights |
||||
SEGMENT EDITOR |
||||
Add attributes to segment |
||||
Add list from query |
||||
Add list from upload |
||||
Delete uploaded list |
||||
Refresh segment insights |
||||
Save segment |
||||
Upload list |
||||
View segment details |
||||
View tables |
Campaigns¶
The following table shows which policies enable user actions within the Campaigns page.
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
View Campaigns page |
||||
CAMPAIGNS |
||||
Analyze campaign results |
||||
Archive campaign |
||||
Delete campaign |
||||
Download campaign recipients |
||||
Download campaign results |
||||
Duplicate campaign |
||||
Open campaign editor |
||||
Search campaigns |
||||
View campaign history |
||||
View one-time campaigns |
||||
View recurring campaigns |
||||
CAMPAIGN EDITOR |
||||
Choose destinations |
||||
Edit campaign |
||||
Edit destination attributes |
||||
Schedule campaign |
||||
Set external campaign launch date |
||||
Use segments as audience |
||||
Use segments as exclusion lists |
||||
Use segments as sub-audiences |
||||
View delivery summary |
||||
NOTIFICATIONS |
||||
View detailed errors |
||||
View notifications |
Destinations¶
The following table shows which policies enable user actions within the Destinations page.
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
View Destinations page |
||||
DESTINATIONS |
||||
Add credential |
||||
Add destination |
||||
Assign data template |
||||
Delete destination |
||||
Edit destination |
||||
View destinations |
||||
DATA TEMPLATES |
||||
Add data template |
||||
Assign to campaign |
||||
Assign to orchestration |
||||
Delete data template |
||||
Edit data template |
||||
View data templates |
||||
ORCHESTRATIONS |
||||
Add orchestrations |
||||
Assign database exports |
||||
Assign queries |
||||
Delete orchestrations |
||||
Edit orchestrations |
||||
Run orchestrations |
||||
Search orchestrations |
||||
View orchestrations |
||||
View query |
||||
ORCHESTRATION GROUPS |
||||
Add orchestration group |
||||
Delete orchestration group |
||||
Edit orchestration group |
||||
Run orchestration group |
||||
View orchestration groups |
||||
PROFILE API |
||||
Add endpoint |
||||
Delete endpoint |
||||
Edit endpoint |
||||
Run endpoint |
||||
Set refresh schedule |
||||
View associated query |
||||
View Profile API endpoints |
||||
NOTIFICATIONS |
||||
View detailed errors |
||||
View notifications |
Users & Activity¶
The following table shows which policies enable user actions within the Users & Activity page. (The icon indicates an allowed action.)
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
View Users & Activity page |
||||
API KEYS |
||||
Generate API token |
||||
Regenerate API token |
||||
View API tokens |
||||
MANAGE USERS |
||||
Add users |
||||
Delete users |
||||
Download activity logs |
||||
Edit users |
||||
View activity logs |
||||
View users |
Workflows¶
The following table shows which policies enable user actions within the Workflows page and access to workflows from within notifications located on the Sources, Customer 360, Queries, and/or Campaigns pages.
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
View Workflows page |
||||
WORKFLOWS |
||||
Configure workflow alerts |
||||
Run workflow actions |
||||
View workflows |
Credentials¶
The following table shows which policies enable user actions within the Credentials page.
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
View Credentials page |
||||
CREDENTIALS |
||||
Add credential |
||||
Delete credential |
||||
Edit credential |
||||
View credential |
Data Explorer¶
The following table shows which policies enable user actions within the Data Explorer.
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
Open Data Explorer |
||||
Explore data |
||||
Select database |
||||
View tables |
Sandboxes¶
The following table shows which policies enable user actions within sandboxes.
Important
The DataGrid Administrator is the policy to which users who will make configuration changes to their tenant should be assigned.
Use a sandbox to configure and validate all changes before pushing those changes to your production tenant.
Changes may only be promoted to your production tenant after changes have passed validation in the sandbox.
Actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
|---|---|---|---|---|
Access sandboxes |
||||
Add sandboxes |
||||
Delete sandboxes |
||||
Pull from production |
||||
Push to production |