Hi there “Process Automation” fans,

Welcome to a new installment of “Process Automation” tips.

It was a valid question from the administration team. They have the “Administration” role applied for our beloved OPA platform and conclude they could accomplish and access far more functionality than expected in the first place. This with, collateral damage in production where the removal of a complete solution (incl. its data!) happened “accidentally” without knowing the consequences of executing the action. Some customers just need to learn it the hard-way, but it’s our duty (as consultant) to advise and to prevent the customer from doing the wrong things!

The initial question was: How can we separate administration roles so the correct people can only do the correct things and can’t access any other restrictive areas of the platform? Here is the answer…

---

Let’s get right into it…

We first assume the development team deployed a great case management solution into a specific organization with which your end users love to work.

Now assume you are the functional (non-techie!) administrator for the OPA platform (not) ‘sysadmin’ for one specific organization. Your account has the “Administrator” role applied which gives you control within the organization; Now for that great question: What exactly can you potentially do that could cause a problem to the organization and the solution with this role applied to your account?

For this, we log out with our developer account (opadev) and login with an administrator account (mine is opaadmin); What do we see in the organization where you deploy a solution via the ‘Application Deployer’ artifact (like in production!)? Well, we see this:

This is in more details what you can do and what you should definitely not do (or even have access to):

Artifact	Potential harm	Access?	Notes
AI Configuration	Manipulate AI settings	❌	Adding a new AI (external) broker might interfere company policies. Removing it makes sure your users can’t use it anymore
Application Deployer	No harm; only read package details	✅	Here you can get details which version of the solution package is installed. Undeployment is not possible here; unless permitted from ‘/system’!.
Applications Manager	N/A	❌	You will never use it unless you work with “staging” packages, but I never seen such customer (yet!)
Archive Administration	Restore/delete instances (BPMs, lifecycle, tasks, notification)	❌	It’s the UI for the good old “Archive framework”; When configured from a technical standpoint, you can damage the solution dramatically on archived dependencies
Audit Viewer	Pure viewing of audit details	✅	You do configuration in the ‘/system’ organization, so this is fine
Case Instance Manager (CIM)	Yes, when closing lifecycles	✅	Know what you do, but required to see what is happening with your lifecycle instances related to the entity instances
CoBOC Transaction Monitor	N/A	❌	You don’t need it
Database Metadata Management	Yes, when changing security/audit details	❌	This view shows DB details over a configured DSO via the WS-App Server service container; Allow only technical admins!
Deployed Process Models	Yes, when leaving the logging to high	✅	Here you see what BPM templates are deployed and you can overrule the log-level in case of more monitoring
External Services Configuration	Yes, by manipulating the URLs/credentials	❌	Changing these URLs can harm BPMs that depends on it; This works together with the UDDI connector
FTP Configuration Manager	Yes, by manipulating the host/port/credentials	❌	Changes can harm dependent actions (like service call from a BPM)
HTTP Connection Manager	Yes, by manipulating the URLs/credentials	❌	Changing these URLs can harm BPMs that depends on it; This works together with the HTTP connector
Inactive Users Tasks	No harm	✅	When you have inactive users that have relevant tasks this makes it possible to delegate them to someone else.
JMS Connector Configuration	Yes, when changing connection details	❌	Changing the wrong setting will have an impact on the JMS system; Like RabbitMQ or ActiveMQ
LDAP Explorer	Yes, when changing security	❌	This artifact is a view on the CARS (OpenLDAP interface) dependent to the platform; Just leave it
License Viewer	No harm	✅	Can be handy with OpenText support requires the details; Licensing itself happens via OTDS since OPA 24.1
Log Viewer	No harm	✅	Great for viewing log details, but it’s better to have a “view”-share on the logfiles on the server with a tailing tool
Manage Blocked Pollers	Yes, only when you use JMS	❌	When your JMS-poller is not functional anymore for whatever reason
Manage renamed users	No harm	✅	When you have components in your UI that show old usernames, this tool (since 24.4) can solve it
Migrate business calendars	No harm	❌	Only for technical admin when you have a legacy of business calendars; Since 24.3 there is an enhancement
My inbox	No harm	✅	It’s the old inbox every regular user has access to; In runtime there is a new inbox node in the regular homepage
OCP Configuration Manager	Yes, when changing tenant details	❌	This is your link to the OpenText Cloud Platform at developer.opentext.com
OT Intelligence Connection Manager	Yes, when changing host/credentials details	❌	This is your linking pin to OpenText Magellan BI & reporting (aka iHub)
Process Archival Manager	Delete BPM instances	❌	This was the tool before “Archive Administration”; Still works for pure BPM instance removal
Process Instance Manager (PIM)	Yes, when terminating BPM instances	✅	Know what you do, but required to see what is happening with your BPM instances
RPA Configuration	Yes, when changing connection details	❌	Robot Process Automation (RPA) to automate repetitive tasks with external third-party tools but watch out for tools like “Knowledge Discovery” (IDOL) and Operations Orchestration!
Schedule Manager	Yes, by stopping it	✅	You want to have control when it runs and need to stop it if required, but know what you do…as with everything
Security Administrator	Yes, by changing OTDS connections	❌	When the OTDS connection is gone, nobody (except ‘sysadmin’) can login
Synchronize Service Containers	No harm	❌	It’s a technical thing with multi-node environments where things need to be in sync.
System Resource Manager	Yes, changing service groups or service container settings	✅	You need access to see if services are up and running, but watch what you’re doing as changes will have an impact!
Test Web Gateway	Yes, by overloading the gateway with requests	❌	It’s a testing tool for technicians, leave it alone…Especially on production
User Manager	Yes, by applying roles to incorrect users	❌	You do role assignments better in OTDS with a consolidation to OPA
Web Gateway Monitor	No harm	❌	There is no need using it from a functional administration role
Web Service Interface Explorer	Yes, calling update/delete operations	✅	You need access to do proper analysis of functional problems with this tool, but know and understand what you do!
XML Store Explorer	Yes, by manipulating XML details	❌	The XML store is a specials DB area storing XML data; Mostly configuration items for the platform and your solution

That’s a fascinating overview (larger as expected, but worth the time writing it), but what else can we do which we should not be able to do?

Well, regarding that question we move into the administration console of the platform at /app/admin where we can select the deployed solution and do several risky tasks!

Firstly, setting the solution to read-only:

Never do this with proper communication and collaboration within the business!

Secondly, change the solution “global” parameters:

This is a gray area where non-techie admins could have access, but (when solidly build) you can also access it directly with the proper URL if the security of the configuration entity allows it! So, there is no need to access it via /app/admin

Thirdly, deleting the solution:

Never, ever hit this button in production! You will remove the solution including ALL solution data in the database. So, always make sure you have backups, but that’s another topic…not for now.

Fourthly, in runtime (/app/start) you have access to the identity package details and can manipulate it:

This is a task for non-techie admins, but still, you need to know what you’re doing here as your solution depends on it.

Ok, are you scared enough now? 😱 Let’s see how we can nicely restrict thing!

---

The restriction area

We’ll first do it the “dirty” way to see the concept working, and then we’ll implement it nicely (incl. OTDS sync.)! Go to the ‘User Manager’ artifact in the production organization and remove the “Administration” role from the users you want to restrict. After this select the “Internal roles” option and assign the roles you genuinely want:

As functional admin, you now see a minimal set of artifacts:

Be aware of the organizationalAdmin role which exposes more artifacts (like ‘XML Store Explorer’) than required, but that’s a necessary evil…It’s what it is!

In runtime, you see the proper nodes required for runtime administration:

Finally, and highly important!, have a look at /app/admin which will now have a restriction (because of removing the “Administrator” role!):

…

A better approach on this concept is creating a new organization role FunctionalAdministrator from the ‘User Manager’, assign the internal roles to it (as sub-role), and apply this new role to your user:

Just for your (and mine) overview, the several types of roles you can use within OPA:

• “Functional role”: You get specific access to resources within the organization, and you can use functional roles within organizational units. You can push these roles to OTDS.
• “Application role”: You get specific access to resources within the CAP package. The main difference with functional roles is that you can’t use application roles within orgUnits. You can push these roles to OTDS.
• “Internal role”: You get specific access required for an activity. The platform delivers these roles, but you can create your own; These roles stay within the platform and will NOT push to OTDS!
• “Instance role”: You create it from the ‘Sharing’ BB for an entity to instantly share the case to others to get temporary access.
• “Organization role”: You create it from the ‘User Manager’ helping you to structure roles in the organization and mapping them with OTDS roles. These roles stay within the platform and will NOT push to OTDS!

The only disadvantage now is the usage of non-sync. roles to OTDS, but that’s something we can solve in a straightforward way!

---

The OTDS sync

Ok, that was the quick and dirty way via the organization/internal roles…Now for a solid implementation (over an OTDS consolidation!) and the only way to do this with OTDS is making use of a “Functional” or “Application” type of role from a solution!

So, create a new workspace with project in your development organization. Then create a folder-structure and create a first ‘Role’ type of document:

You can create the role like this; with no further sub-roles (for now!)

Do a publication and go to the ‘User Manager’ artifact where you try to assign the previous created organization role FunctionalAdministrator to the new fun_admin:

Yes, you’ll get an error! Where you can’t modify an Independent Software Vendor Package! Aha…Now what?

Don’t assign it the other way around as that will not work! You want to have it like the structure below. So, when you have the role fun_admin assigned, you inherit all role functionality under it!…Yes, read it again as that’s how it works, and it took me also a while to digest it.

• ‘fun_admin’ (functional solution role)
  • ‘FunctionalAdministrator’ (organization role)
    • ‘Audit Viewer’ (internal role)
    • ‘CapAdmin’ (internal role)
    • etc…

So, we need another approach accomplishing our goal for this post which will be the usage of runtime references! WHAT? Yes, that’s a fancy word for reusing components (in our case some “internal” roles) of the platform for your benefits! For this we first add this set of references to our project. That’s an action from the context menu on your project where you select the type ‘Role’. Watch the screenshot closely for the packages you find these roles:

Once in place, open the fun_admin role again and add these runtime references as sub-role:

Do a publication again, assign your administrator role to the fun_admin role by hand (you can remove it also from the FunctionalAdministrator role), and watch what you see now! Well, that’s exactly the same list of artifacts! Watch also the ‘User Manager’ again where fun_admin now nicely has those sub-roles assigned:

That a party! 😎

You see also the FunctionalAdministrator is out of scope now with a solid implementation in your project.

And the beauty is that you can push fun_admin now to OTDS from the ‘Security Administration’ artifact:

AND in OTDS you can nicely assign this “runtime-ref-enriched” role to your administrator account:

WITH a consolidation back to OPA…

Again, a party! 🥳

You can read more about this push/consolidate movement here

I was just ReThinking, but every project should have this type of “Functional Administration” project to introduce a new layer of administration to their OPA platform. So, here you have the download link for the CAP file (version 25.2) for the “Functional Administration” project you can use…I will not further maintain it, but this post already gives a lot of insight how to do it yourself!

FYI: my deployment (via the ‘Application Deployer’ artifact in ‘/system’) in a test organization was a success incl. all the pushing/consolidation from an OTDS perspective.

---

That’s a “DONE” on splitting administration roles across the correct people! Nice, everyone always told me (also by OpenText) this isn’t possible!? Well, now you see why I do these posts online to bust the impossible and inform you on the possibilities of the OPA platform. Never give up on a first answer and do your own research as “trust is good, but control is better”…Have a great weekend; Cheers! 🍹

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The Process Automation guy”?