Showing results for 
Search instead for 
Did you mean: 


The Incorta admin user account is a super user with special privileges to govern and administer the platform. It is important to understand the role of an administrator before deploying Incorta in your environment. In this article, we discuss the best practices concerning the use of the admin user account. Take note that Incorta provides separate admin users for the main analytics platform and the CMC (Cluster Management Console). There could be a potential overlap of management functions between these two roles in some areas. The focus of this article is on the admin user responsible for the analytics platform. 

What you need to know before reading this article

The usage of the admin user should be understood in the larger context of building and securing the Incorta platform.

Let's Go

Admin User - Common Tasks

Some of the common tasks performed by an Incorta administrator are: 

  • Manage users and access 
  • Manage data sources 
  • Manage Schemas, Business Schemas, Content access, Content configurations and Loading schedules
  • Review, monitor and audit platform usage 
  • Work alongside infrastructure owners and the Incorta application owner for upgrades and patch fixes 
  • Migrate content and support content development 
  • Integrate with other systems 
  • Perform Cluster Management Console (CMC) administration tasks
  • Troubleshoot issues, work with Incorta Support

Admin User - Best Practices

The following best practices span the list of typical activities managed by Incorta Administrators.

Manage Users and Access Permissions

A common task for administrators is to manage users.  Here are some best practices for managing Incorta users.

Recommendation Comments

Grant permissions via Groups


Only grant permissions to groups, not to individuals.  This allows you to manage roles and permissions at the group level instead of the user level which will save time and provide better control.

Set up user admins

As long as user admins are trained to properly maintain users and permissions at the group level, this will reduce the burden of user maintenance if maintaining users and groups in Incorta directly.

Use a directory service to sync user data

Integrate Incorta with LDAP or another service to maintain users and groups centrally instead of in Incorta directly.

Use preexisting user and group processes

Use the same group definitions in Incorta that you use in your source system to manage Incorta content access in the same way.  This provides continuity for your users as well.

Limit admin access

Limit the number of users with admin credentials to one or at most 2-3 trained administrators so that you have backups in case the primary admin is unavailable.  This minimizes the chances that changes to the system can be made anonymously.

Update the admin password regularly

Update the admin password regularly as per your security policy.  Alternatively, use SSO to eliminate the need to maintain user passwords in Incorta.

Do not use generic or shared accounts for users

Every new Incorta user account should be identified to a specific user from the company directory.  Do not allow users to share accounts.  This will enable you to audit Incorta usage.  Use SSO to eliminate this threat.

Assign correct privileges to users

Make sure to assign only the appropriate permissions to Incorta users.  Review platform permissions periodically to make sure they are correct (see metadata dashboard).  See these Security Guidance Articles for more suggestions.

Remove users who no longer use Incorta

Delete or deactivate the privileges of users who no longer use Incorta.  When you delete, you can assign any objects/content owned by these users to the appropriate still active user.

Create and Maintain Incorta Development Guidelines

Having common standards for your Incorta configuration will streamline object creation and will make it easier to understand the work done by others.

Recommendation Comments

Follow standard naming conventions


Develop and follow standard naming conventions when naming objects in Incorta.  Use these articles for reference:

Name data sources by source not by environment

Do not use names like “UAT” or “Prod” when naming data sources as these will be migrated with the same name to all of your environments even if you do not, for example, intend to allow access to production data in your UAT environment.

Maintain Multiple Environments

Administrators should administer different environments for different purposes.

Recommendation Comments

Maintain separate Dev and Production environments

Maintain different environments for different purposes so that, for example, development work does not get interrupted by UAT work.  There should be a minimum of two environments with Production having its own right sized cluster.

Use Prod equivalent cluster for testing

It is best to have at least one other environment that is sized and configured the same way as your production cluster so that you can fully test the impact of changes that you plan to introduce into Production.

Control content creation in Production

To prevent the possibility of Production activities being impacted, development and testing work should take place in a lower environment and users with the privileges of adding objects (schemas, dashboards) should be limited in Prod.

Use Change Management Requests

Establish or take advantage of existing change management processes (e.g. from an inhouse IT desk/Training Dept) when introducing new use cases to Production.

Back up Incorta Tenant Regularly

The Incorta tenant can be used to restore or migrate all of the configuration you have created separately from the data.  It is important to extract and back it up on a regular basis in case an issue occurs.

Recommendation Comments

Back up the tenant regularly

Schedule tenant backups from the CMC daily or more frequently.  Incorta can maintain up to 30 tenant revisions.

Disaster Recovery

Consider implementing a Disaster Recovery (DR) environment.  In the event of a crash, there may be data (snapshot data for example) that cannot be recovered by running full data loads.  Backing up the data files can be implemented as part of a DR strategy.

Backup objects when working on them

It is a good idea to extract a copy of an object before performing changes to the object so that it can be easily restored if needed.

Communicate Service Downtime

Good communication is always important and will keep your Incorta users happy.

Recommendation Comments

Notify your users of scheduled down times

Use the appropriate notification channel to make sure your users know about planned outages ahead of time.  Downtime may be required for upgrades to the Incorta software or Incorta infrastructure or even for content migration.

Account of load schedule stoppage

Make it clear in your communication if the load schedule will be stopped in advance of Incorta being taken down and when normal loads have resumed.

Monitor Incorta

It is important to monitor Incorta to prevent degradation of user experience.

Recommendation Comments

Monitor processes

Like any application, Incorta should be monitored for activity that requires intervention.  See this article on what to monitor in Incorta.  You can also check out the Monitoring and Hardening Your Environment and Security sections of the Best Practices index on Community.

Create alerts

Use alerts to notify you of data or other conditions that may require you to take action.  See this Alerting article for suggestions on what to implement.

Clean up Unused Objects

Inform object owners of unused objects and regularly clean them up to minimize your Incorta footprint and make it easier to organize your content.

Recommendation Comments

Identify Unused Objects

Use the Unused Objects dashboard which comes with Incorta Tools to find the objects that get little to no usage.  Refer to this article for the advantages of and how to use the dashboard.

Delete Users

The admin can delete users and at that time can review and reallocate ownership of the content they owned.  If not needed, the content can be assigned to the admin who can then delete it after taking a backup

Share with Admin Users

Incorta, for security purposes, does not allow any one user to edit or even view all content automatically from the Incorta UI.  This means that the admin user may not see or be aware of all entities that have been created.

Recommendation Comments

Share all content with the admin group

If you would like the admin to have access to all content in Incorta, define and document a process in which all Incorta object creators are trained to share what they create with the admin group.

Use Incorta Tools to identify all objects

Incorta provides a dashboard with the Incorta Tools that helps administrators identify entities that they would not be able to see otherwise and their owners.  Once identified, you can work with the owner of the object to have them share it with you or assume their identity to share it.

Related Material


Best Practices Index
Best Practices

Just here to browse knowledge? This might help!

Version history
Last update:
‎08-17-2023 02:53 PM
Updated by: