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:
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.
Sandbox Administrator¶
The Sandbox Administrator policy allows full access to sandboxes, including the ability to push changes in a sandbox to production.
Important
The Sandbox Administrator policy is only assigned to users who are assigned the Full Administrator policy.
The Sandbox Administrator policy may not be assigned to users who are assigned the DataGrid Administrator policy.
SLA Administrator¶
The SLA Administrator policy allows full access to SLA settings for queries and orchestrations.
Full Administrator¶
The Full Administrator policy is assigned to employees of Amperity and allows a user to perform all actions.
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 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.
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 table lists the policies that may be assigned to users of Amperity, along with the allowed actions that are associated to each policy.
Note
The following icons indicate when a policy allows access.
– A user has read/write access. (Within the User Interface section this indicates the user has access to the tab itself.)
– A user has read-only access.
– Actions that can be restricted (downloads and viewing profile data).
– Actions that can be done when a user is assigned the user administrator policy option.
POLICIES |
||||||
|---|---|---|---|---|---|---|
ALLOWED ACTIONS |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
User Interface |
||||||
Sources |
||||||
Stitch |
||||||
Customer 360 |
||||||
Queries |
||||||
Segments |
||||||
Campaigns |
||||||
Destinations |
||||||
Admin |
||||||
Campaigns |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Add segments to campaign |
||||||
Analyze campaign results |
||||||
Choose destinations |
||||||
Delete campaign |
||||||
Download campaign results |
||||||
Edit campaign |
||||||
Schedule campaign |
||||||
View campaigns |
||||||
Courier groups |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Add, edit |
||||||
Delete |
||||||
Run |
||||||
Schedule |
||||||
View |
||||||
Couriers |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Add credential |
||||||
Add, edit |
||||||
Delete |
||||||
Run |
||||||
View |
||||||
Data explorer |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Explore data |
||||||
Select database |
||||||
View tables |
||||||
Data exports |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Activate |
||||||
Add, edit |
||||||
Delete |
||||||
Select tables |
||||||
View |
||||||
Data templates |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Add, edit |
||||||
Assign to destination |
||||||
Assign to campaigns |
||||||
Delete |
||||||
View |
||||||
Database editor |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Activate |
||||||
Configure databases |
||||||
Configure tables |
||||||
Set as customer 360 |
||||||
Regenerate, run, stop |
||||||
View databases and tables |
||||||
Databases |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Manage databases |
||||||
Review validation reports |
||||||
Run databases |
||||||
View databases and tables |
||||||
Destinations |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Add credential |
||||||
Add, edit |
||||||
Delete |
||||||
Assign data template |
||||||
View |
||||||
Domain SQL |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Add, edit |
||||||
Delete |
||||||
View |
||||||
Domain tables |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Delete |
||||||
View |
||||||
Feeds |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Add, edit |
||||||
Delete |
||||||
Load new data |
||||||
View |
||||||
Ingest SQL |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Add, edit |
||||||
Delete |
||||||
View |
||||||
More actions |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Download activity logs |
||||||
Manage BI Connect |
||||||
Manage users |
||||||
View activity logs |
||||||
View Credentials |
||||||
Notifications |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Subscribe |
||||||
View |
||||||
View detailed errors |
||||||
Orchestrations |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Add, edit |
||||||
Assign database exports |
||||||
Assign queries |
||||||
Assign segments |
||||||
Manage groups |
||||||
Manage schedules |
||||||
Delete |
||||||
Manage SLA |
||||||
View |
||||||
View groups |
||||||
View schedules |
||||||
PII |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Download |
||||||
View |
||||||
View orchestration logs |
||||||
Queries |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Activate query |
||||||
Add to orchestration |
||||||
Build query |
||||||
Delete query |
||||||
Download query results |
||||||
Enable query alerts |
||||||
Manage folders |
||||||
Rename query |
||||||
Run query |
||||||
Select database |
||||||
Use visual queries |
||||||
View folders |
||||||
View orchestrations |
||||||
View queries |
||||||
Sandboxes |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Pull from production |
||||||
Push to production |
||||||
Edit SLA settings |
||||||
Segments |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Add to campaign |
||||||
Delete |
||||||
Download segment results |
||||||
Edit |
||||||
Explore customer records |
||||||
Manage folders |
||||||
Manage segments |
||||||
Recommended segments |
||||||
Rename |
||||||
Save, discard |
||||||
Search |
||||||
Segment insights |
||||||
Select database |
||||||
Set default charts |
||||||
Use SQL segments |
||||||
SLA |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Edit SLA settings |
||||||
Set segment as SLA |
||||||
Stitch |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Edit Stitch settings |
||||||
Explore Amperity IDs |
||||||
Run Stitch |
||||||
View semantics |
||||||
View Stitch report |
||||||
View Stitch settings |
||||||
Workflows |
Amp360 User |
AmpIQ User |
DataGrid Operator |
DataGrid Admin |
SLA Admin |
Sandbox Admin |
Run workflow actions |
||||||
View workflows |
||||||