Hi there “Process Automation” fans,

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

What is it with dynamic security customers always want to create? Just a simple role isn’t enough; they (the “knowledge worker”) must be in control who gets access to the entity instance? Why? Would be my first question! Is it all so confidential? Do you really want to restrict it all? Restriction also comes with a penalty as “with great power comes great responsibility”. Most of the time keeping a track-record (via history/audit) is enough to scare people off doing the wrong things. So, it all depends on company policy and the trust within the company.

Normally you would create a set of roles, apply users to the roles, and define what functionality is available for the role. For those who are not convinced, this post will demonstrate how to make security dynamic based on a list of memberships/participants on the entity instance.

---

Let’s get right into it…

Boot up your machine, dive into your workspace with correspondent project, and create yourself a brand-new entity ‘Case’:

With this entity in place, we add a new ‘toMany’ type of relation to entity “Person” of the identity package which OpenText delivers with the platform:

This relation will represent the members/participants of the case. From the ‘Create’ form, we can drop the relation onto it:

You see me doing some fancy options…That’s not only to make this post look, but also to show you the possibilities!

Do a first publication now and see what is possible in runtime…It’s just a basic CRUD implementation of ‘Case’ instances; Nothing fancy, nothing great so far!

…

Now create a new ‘Role’ type of document with the name of fun_participant

Do a publication and make sure you apply this role to your test account (a non-dev account!) from the ‘User Manager’ artifact:

Great, but now what? Logging in with this test-account (in a new incognito tab!) does not show anything (yet!)…Except for the default Homepage!

Back to the ‘Case’ entity to add the ‘Security’ building block to it with our new role who can do only updates:

That second role ‘Identity Administrator’ has full access with all the checkmarks selected in the ‘Security’ BB.

Publish and double-check in runtime…So, your administrator/developer account can create new case instances; with the test-account you can only update it!

…

Now for the fun part of the post as we want to make the security dynamic so our test-account can only update the ‘Case’ instance when they are in the list of “Participants” of the case and not always (as configured now!). So, that sounds to me like conditional security!

Back to the security for the fun_participant role where you can add a new condition:

You see me already removing the update checkmarks for the ‘to_many_person’ and ‘Title’ because we don’t want our test-“participant”-account to add himself to the list!

How should this condition look like? Well, it’s an advanced type of expression looking like this:

For you to copy: (item.to_many_person[].Properties.User_ID).contains(User.Properties.UserId)

After creation of the condition, you can apply it to other “update” related things; Or even to other “read” related things:

So, how to assess this after publication? Watch these steps and switching accounts on each step:

1. dev-account: create a case instance without any participants
2. test-account: check if you can open the case, but you can’t update any fields (except for the ‘Start date’ which I forgot to conditionize…After my own post review)!
3. dev-account: add your test-account as “participant” to the list
4. test-account: check if you can open the case, AND you can now update the relevant fields!

That’s a party!…😎

---

That’s a “DONE” on dynamic security over an entity participants list. Fascinating to see how dynamic the security building block for an entity can be! Again, be careful on these conditional security implementations as they make your security also complex where simplicity is most of the time more clear and easier to understand (also for the business). Enjoy your weekend, and we see each other next week for another great journey around “Process Automation Tips”. 💪

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”?