Enable reorganization of organizational and functional roles

Dear Janine,

Thank you for this idea! We do have this problem of creating of graphical hierarchy of roles so to make the process of modification much more easier and quicker registered for our R&D team and deploying of such logic is planned for one of future versions. Your idea raised the priority of this problem and we can hope seeing this functionality in one of nearest versions! Thank you for helping us to make our application better!

As for now changing of roles on code level is to risky and demands changes in core, so lets wait for an update from our R&D team.

Best regards,

Oscar

Is there any way to make the re-organization happen? If we do this via scripts, is the SysAdminutUnit table the only one involved?

++++

Sasori Oshigaki,

Greetings,

In theory, you can modify the roles using SQL scripts; however, this process requires caution and a good understanding of the database structure.

Key Tables:

The main tables responsible for organizational roles and their hierarchy are:

• SysAdminUnit: contains information about system roles and users.
• SysAdminUnitInRole: links users to roles.
• SysAdminUnitRole: defines functional roles assigned to users.

To modify the role hierarchy, the ParentRoleId field in the SysAdminUnit table is crucial, as it determines the hierarchical structure.

Risks of Direct Changes:

• Data consistency issues: Direct updates may result in inconsistencies and performance problems.
• Not recommended for production: Such changes should only be performed in a test environment after thorough validation.
• No built-in UI support: Creatio currently does not offer interface-based tools for drag-and-drop or hierarchy reordering of roles.

Although we do not recommend using SQL scripts for production environments, you may apply them for internal testing if needed. Our general recommendation is to wait for full platform support via the UI.

Important Before Running:

• Back up your database.
• These scripts modify the ParentRoleId, which defines the role structure.

Example Scenario:

You want the role hierarchy to be:

• DEPARTAMENT MANAGER at the top,
• Dev Director and Director QA under it (same level),
• Dev and Qa under Dev Director (same level).

Role Links:

Role \ New ParentRoleId

DEPARTAMENT MANAGER \ NULL (top level)

Dev Director \ 62ed9c49-9475-4a96-bca8-648822800b9d

Director QA \ 62ed9c49-9475-4a96-bca8-648822800b9d

Dev \ bc11e256-8578-4642-954b-1e60893a0715

Qa \ bc11e256-8578-4642-954b-1e60893a0715

SQL Script:

-- DEPARTAMENT MANAGER — top-level (no parent)
UPDATE public."SysAdminUnit"
SET "ParentRoleId" = NULL
WHERE "Id" = '62ed9c49-9475-4a96-bca8-648822800b9d';
 
-- Dev Director and Director QA — children of DEPARTAMENT MANAGER
UPDATE public."SysAdminUnit"
SET "ParentRoleId" = '62ed9c49-9475-4a96-bca8-648822800b9d'
WHERE "Id" IN ('bc11e256-8578-4642-954b-1e60893a0715', '24e0365f-68f5-4c9a-9106-43bb48e638f7');
 
-- Dev and Qa — children of Dev Director
UPDATE public."SysAdminUnit"
SET "ParentRoleId" = 'bc11e256-8578-4642-954b-1e60893a0715'
WHERE "Id" IN ('9937d0b2-ba45-4f47-9ea3-45328553ff00', 'aa929414-46e7-4e4e-8211-6e92a688d57f');

Outcome:

• DEPARTAMENT MANAGER becomes the root.
• Dev Director and Director QA are on the second level.
• Dev and Qa are on the third level, both under Dev Director.
  
  
  
  Regards,
  Orkhan