Truedat does not come with any role preconfigured. The user roles are configured at each installation. You can create as many user roles as necessary customizing each one with the corresponding permissions. Note that the permissions defined in a role will apply to a user only on the domain in which the user been assigned that role and also in all the descendant subdomains.
To create a new role simply click on the button and enter the name that we want to give to the new role:
If we click on one of the roles we can edit the permissions assigned to the role or the name by clicking on the name:
The permissions defined in the application are divided in the following modules:
Assigning any of these permissions will provide access to the user to the menu option "Business Glossary->Drafts" where the glossary is managed.
Create business concepts: allows you to create a concept and also bulk upload via a csv file.
Delete business concepts: to delete business concepts in draft status.
Deprecate business concepts: to delete business concepts that have already been published.
Manage business concept links: to establish the relationship between concepts. Also to link a concept to a structure in the Data Catalog.
Manage business concept domain: to modify the domain the concept is assigned to.
Manage confidential business concepts: this permission will allow you to mark those business terms that are confidential and view them. You need this permission in addition to other permissions related to concepts to be able to perform the corresponding actions with concepts that have been marked as confidential. For example, in order to view confidential concepts from a domain, you will need the "View concepts" permission and also "Manage confidential business concepts".
Publish business concepts: to publish those concepts that are in Reviewing status.
Reject business concepts: to reject those concepts that are in Reviewing status.
Request business concept approval: to submit for review and approval concepts in Draft status.
Share business concept with domain: to share a concept with another domain. This can be useful in multi-entity organizations.
Update business concepts: to edit and modify the details of a concept in both draft and publish status.
View business concepts pending approval: to view those concepts that have been submitted for approval.
View draft business concepts: to view concepts still in draft status.
View rejected business concepts: to view those concepts that have been rejected.
Allow the user to view the Glossary:
View published business concepts: to view the published version of concepts.
View versioned business concepts: to view old versions of published concepts.
View dashboard: to view the general data governance dashboard.
Permissions for viewing and managing data structures in the data catalog:
Link structures: allows you to link a structure to concepts. You will also need the permission 'Manage business concept links'. The linkage can be done from the concept in the Business Glossary or from the structure in the Data Catalog.
Link tags to structures: allows to link a tag to a structure in the Data Catalog. Tags have to be previously created by an admin.
Link structure to structure: allows you to link structures from different systems and delete those links. You will need this permission on the domains of both structures.
Manage confidential structures: allows you to view those structures that have been marked as confidential and depending on other permissions you may have, manage them.
Manage structure domain: to update the domain of structures, both individually and via bulk upload.
Execute structure profiling: to run ad-hoc data profiling on a structure from the Data Catalog.
View structures: to view structures in the Data Catalog.
View structure profiling: to view the data profile of a structure if this is available.
View protected metadata: to view metadata that has been loaded in the Data Catalog as protected.
View note: to view the latest version of the note with functional metadata.
View notes history: to view previous versions of the notes of a structure.
Permissions for viewing and managing notes of data structures in the data catalog:
Create note: to create a note with functional metadata.
Delete note: to delete a note in draft status.
Deprecate note: to delete a published note.
Edit note: to edit a note in draft status or if the note is already published, to create a new version.
Publish note: to publish a note from the status Pending approval.
Publish note from draft: to publish a note directly from Draft status without having to go through the approval workflow.
Reject note: to reject a note that was sent for review.
Send note to approval: to submit a draft note to be reviewed and approve.
Un-reject note: to change a note that has been rejected to Draft status in order to edit and make the necessary corrections.
Manage rules: to create, modify and delete quality rules.
View quality: to view quality rules, quality implementations (in published status) and quality dashboard.
Manage basic implementations: to create, modify and delete (from draft, pending approval or rejected status) basic quality implementations. This permission is also required to upload implementations via csv file.
Manage form implementations: to create implementations using the multi-step form, modify and delete (from draft, pending approval or rejected status) them.
Manage native implementations: to create, modify and delete (from draft, pending approval or rejected status) quality implementations of the native type.
Manage implementations without rule: you will need this permission in addition to the ones above if you want to work with implementations that are not linked to any quality rule.
Review implementations: to review implementations submitted for approval and either publish or reject them and also to deprecate published implementations and recover them from archived to published again or delete them permanently.
Execute quality implementations: enables the option to run an ad-hoc execution of the quality implementations.
Link implementations to concepts: to link an implementation quality to a concept.
Link implementations to structures: to link an implementation quality to a data structure.
Manage remediation plans: to create and edit remediation plans linked to the execution of an implementation.
Manage quality execution results: to upload quality results via csv file.
Manage implementation segments: when creating a new form implementation this permission allows you to set up the segmentation criteria so the results are drilled down by it.
Create grant request: to request access to data structures and modify existing grants.
Allow grant requests from third parties: so other users can request access on your behalf.
Create grant requests for third parties: to create an access request on behalf of another user.
Request grant removal: to request a data access to be removed. If the user has this permission, the request does not need to be approved. But if a user does not hold this permission, they can request the removal of their access, but it will have to be approved by a user with permission to "Approve grant request".
Request grant removal for third parties: to request the removal of another user's grant. If the user also has permission to "Request grant removal" then the request will be submitted without having to be approved.
View grants: to view the accesses that have been granted.
Approve grant request: to approve/reject access requests and requests to modify and remove granted accesses.
Manage grants: to create, modify and revoke grants.
View lineage: to view lineage from both the Lineage module and from the structures on the Data Catalog.
Permissions for managing the taxonomy / data domains:
Create domains
Delete domains
Modify domains
View domains
Permissions for managing role assignments to a user in a domain:
Assign a role to a user / group in a domain
Delete role of a user / group from a domain
Update the role of a user / group in a domain
A role can be designated as the default role for the platform. Only one role can be the default role. The permissions on the default role will apply to any user who queries a domain in which the user has no role. In the event that a user is assigned a role within a domain, the assigned permissions will always be in addition to the permissions acquired by default with the default role.
If a default role is not defined, if a user does not have any role defined in any domain, when entering the application, they will be informed that they must consult their administrator to configure the appropriate permissions. This message can be personalized in each installation, indicating the appropriate contact form.
Depending on the user's permissions in the different modules, they may or may not see the menu options. A menu option will be visible to a user as long as they have at least one permission from that module on any domain. Otherwise, the menu options will not be visible preventing them to perform any action or view information they do not have permissions to.
