/ Development  

Working with tasks (role/team/worklist/personal)

Hi there AppWorks fans,

Welcome to a new installment of AppWorks tips.

In this post we’ll cover this screenshot from runtime:


  • How do we get tasks in these boxes/categories for our beloved end-users?
  • What is the difference between roles- and teams-tasks as it sounds for me the same?…we’ll see!
  • And what is a worklist? Is it a queue type of thing?
  • What will happen on a ‘groups’ type of tasks (like teams / worklists) when it’s picked up by multiple users at the same time?
  • Is there a way to configure that all users from a group need to finish the task or only 1 user from the group (or maybe even a percentage of the group)?


Let get right into it…

Your daily task: Spin up the VM and open your project with the developer rolled user account!

How to start?…Well, task generation happens from lifecycles and BPM’s so let’s start with that…shall we?

We just start with a simple ‘case’ entity this time with nothing special…just the basic stuff and as we’ve seen the 20.3 release we can generate a basic structure for this!

So, from the ‘entities’ folder in your project we’ll create a new ‘case’ entity with this screen as input (where you keep that mark to generate all the fancy stuff for us):


After this generation force you can save the entity as ‘case’, and we’ll continue by adding the ‘Lifecycle’ building block where we craft something nice like this. Let me know in the comments if you need more guidance?


Now we go to the properties for each task where we can configure the ‘Work Assignment’ for the activity…

One thing I forget to say…As we have that property ‘case_unit’ with type ‘Enumerated text’ we are required to add some values, so we pass the validation of our project.



Select the type ‘Organizational Unit’…Yeah…I know!…It’s the same term for ‘Team’, and those tasks will land into the ‘Teams Tasks’ in runtime…trust me!

I also made it a static value of ‘AppWorks Tips’…Why that value?…Because I created a brand-new organizational unit on the identity homepage in runtime.


The end-result:



Assignee type can be ‘Role’ with again a static value, but we can’t type in the field as we need to select a ‘Functional’ role as value! Hit that search icon on the right side and create a new role…

What I don’t understand is that in a previous post I created a ‘Functional’ role ‘Manager’ in OTDS and was hoping to be able to select it here after an OTDS push, but that’s not the case…Let’s see if we can solve this later on…Maybe a role in a role!?


Give it the name ‘Manager’ and save it in a nice location like AppWorksProject/nl-bos/roles/functional

Make sure it’s a functional role…The other role types will be covered in a separate post…It’s placed on the backlog!


The end-result:



Well, I already created a new ‘Worklist’ on the identity homepage in runtime with the fancy name ‘DevWorklist’, and we can just use that name as static value…


The end-result:



This is the only type where the value will be received from a property. In our case we just created a new property on the case with the name ‘case_assignee’. Make sure this property is a bit longer that the regular 64…I made it 256! Why?…You’ll see later on.

Make sure you also add this new property to the forms, layouts, and the lists!


The end-result:


You see that we use static values for most of this configuration…Maybe not smart for a real solution…It depends! You are always free to grab a value from a property on your entity as you probably already discovered yourself!

Notice the icons in the lifecycle with an end-result like this (that you can save and deploy!):


Time to save things and do a first deploy…shall we?

That’s a green light for me:


Next is testing…right?…Well…Maybe we’ll first cover the next section…

Assigning users to our work

Now we have our ‘team’, ‘role’, ‘worklist’ and ‘user’ work assignment in place, it’s time to make sure we have some users in place that can handle those tasks…A team with zero members will not do the trick…correct!? 😜


In runtime open the identity homepage and go to the crafted ‘AppWorks Tips’ organizational unit…In this entity instance you see a tab called ‘Positions’, and a tab called ‘Members’. For my post I crafted some positions like ‘Developer’, ‘CEO’, Tester’ and ‘Consultant’.

In the ‘Members’ tab I added some users to those roles!


So, I have a ‘dev01@awt’ in the ‘Developer’ position, and I have a ‘user01@awt’ in the ‘Tester’ position so both ‘Team’ members ‘see’ a task…hopefully (as that’s sound like the theory behind a team!?)


Well, for the role we crafted a new functional role ‘manager’ in design time…correct? That role should be available in the ‘User manager’ artifact!

And it is…


What do we also see…YES…The other ‘Manager’ role that was synchronized from OTDS (see that slightly different icon!). But was that OTDS ‘Manager’ not visible in the identity homepage for the ‘All groups’ list?


Ohw man…If you understand this logic?…I don’t!?

Let’s open that ‘Manager’ role in runtime to check the members, as I could remember that I placed the ‘admin01@awt’ user as member to that role in OTDS that I also consolidated to AppWorks!


There you have it…

So, that should be the same in the ‘User manager’ artifact!


That’s indeed a ‘Bingo’…

But then we should also be able to make the OTDS ‘Manager’ role a sub-role of the ‘internal’ functional ‘manager’ role…You get it!?


Make sure you switch the view to ‘Roles - roles’…On the left side you select the OTDS ‘Manager’ role and on the right side you assign the ‘internal’ functional ‘manager’ role!

OK…Let’s double check in our beloved CMC tool…You know how to start it by now…correct?, otherwise you’ll let me know in the comments!


Looks to me like it’s the other way around now…So we send out the task to the internal ‘manager’ role, but our ‘admin01@awt’ is applied to the OTDS ‘Manager’ role…That will probably not fly into the sky (in theory!)

Let us apply that user also that the internal ‘manager’ role with some other user you like to apply…So we have 2 users in as our ‘manager’ role…internal…functionally…executed from the ‘User manager’ artifact! 😜

From what I see it’s also not a good choice to add members into the OTDS ‘Manager’ role from within the ‘User manager’ artifact as you will not see that update happening in runtime on the identity homepage…Or maybe I need to refresh something, but it’s not happening in my environment. But maybe it’s also not intended to update it from this artifacts as you normally will do this in OTDS administration…In theory!

Next one…


This one is easy as we can just open the created ‘DevWorkslist’ in the identity homepage and apply a ‘Unit’ (aka ‘Team’) to it!



You’ll see this one in the next section as it required some specific information! We also made it a field on the form, so can fill in whatever we like!

Our user assignment is the last of our concern we’ll first test the first 3 tasks to get ourselves a happy feeling.


Let’s do some testing…in runtime!

Enter the ‘runtime’ environment for our end-users. I just use my most simple user ‘user01@awt’…Yes…the one from OTDS! And I only applied this user to the ‘Entity Runtime User’ account, so we see a nice homepage in runtime with our task categories…Nice and clean.


Hmmm…How to create a new case? We don’t see our ‘Default’ case list, and the ‘Plus’ icon in the top right is also empty!?

We saw that before and what we would do is flagging our solution in the ‘/app/admin’ to be available in runtime for our ‘Entity runtime user’. Only we learned in the latest version of the platform this is not needed anymore!?…So now what?…Well, this must be security!

Let’s add a security building block to the ‘case’ entity where we add the role?…Yes…’Identity User’!!


Make sure our ‘Identity User’ gets sufficient permission on the entity…We just mark it all for now.

That’s a ‘save’ and ‘publish’ with a refresh in runtime!

Now let’s create an instance of ‘case’…


Just fill-in some values for those fields and hit ‘Create’…And as we learned from other lifecycle posts we know that it will start on entity creation! So, we should have something in our ‘Teams’ inbox…correct?

Well…There it is…


How come that our ‘user01@awt’ has direct access to this task? Well, because this user applies to the team apparently! Remember that ‘Members’ tab in the ‘AppWorks Tips’ Organizational Unit on the identity homepage…We added a ‘Tester’ position and applied the ‘user01@awt’ to it! OK, but our ‘dev01@awt’ should also be able to access that task!? And a user that is not applied as a member will also not see the task!? For us that’s the ‘admin01@awt’! After some logout/login with those users we see that this assumption it totally correct!!

Let’s do our first test by opening the task with both users (with 2 windows!), so you see that ‘Claim’ button. Hit it for the first user and then for the second user!?

For the first user we’ll get an update back…


Now hit that same ‘Claim’ for the same task with the other user…


Hmmm…Not a very friendly message, but the screen gets updated correctly! When you go back to the task overview for this user you also see the state update from ‘Created’ to ‘Assigned’.

Back to the user that ‘claimed’ the task and let’s complete it for the next stage!

That should be our ‘Role’ task…But for both my users these are empty!? Well, we send it out to the internal ‘manager’ role and as far as I can remember last time we only applied the ‘admin01@awt’ user…You can double-check it in the ‘User Manager’ artifact!

After that double check I was right…let’s dive in the inbox of ‘admin@awt’…There we have it!


Also, here we can ‘Claim’ the task and ‘Complete’ the task for the next step!

The next step will be our ‘Worklist’ task…Well, both my ‘user01@awt’ and ‘dev01@awt’ are members of the worklist, and they both have indeed that task available…So…’Claim’ and ‘Complete’!

‘Complete’?? It fails with an error!!!!…That’s correct as the next step will be our ‘User’ task, and I told you to save the best for last…Check the next section…

The Assignee ID

That last ‘User’ task had a connection to a property on the case. Property ‘case_assignee’…remember? Well, I don’t know what you filled in during the case creation of our test, but it’s empty with my case!

When I take a look on the server log tail -999f /opt/opentext/AppWorksPlatform/defaultInst/Logs/Application_Server.xml I see these messages passing by:

The data is not specified in the property for dynamically reading from the message map.
Target not provided
The request did not process successfully due to missing data.
The "HumanInteraction" request expects "Target" at "HumanInteraction/SendTo/Target"
The error is 'Error occurred while executing the case instance : Error While delivering the human task'.

Good to see that we’re still ‘human’! 😇

How to solve this…Well, let us add some value to the ‘case_assignee’…shall we!


Back to the task where we do the ‘Complete’ again…hmmm…still a failure!?

The message in the logging this time The "HumanInteraction" request did not process successfully because of "the assignee ID 'user01@awt' does not exist.".

OK…an assignee ID!?!?

Well…Back to the ‘User Manager’ artifact…Hit the ‘user01@awt’ account and check his assignee ID at the bottom of the screen!


Copy & paste into the assignee field on our case in runtime


Now complete the task again…Ohw yeah…That’s a green light for me!


Open that task and complete it…There is no need to ‘Claim’ it as it’s a personal task…Specially for you!

Well…All inbox categories ready!…let’s do a double check in the ‘Case instance manager’ artifact in design-time with a nice green result on our ‘case’ instance lifecycle.


This overview is always nice to double check. Especially when more lifecycles start, and you end up in several states…This gives you a nice overview!

Answers on the initial post questions

First a thing to note as for me it’s totally unclear what the difference is for sending a task to a team, role, and worklist!? It handles the task all the same with a ‘Claim’ and ‘Complete’? So, when to use what?

  • Worklist: See this as a big basket of tasks where your team members can work on where tasks can be claimed/revoked and completed. You can apply multiple teams to 1 worklist. See a worklist more like a work queue for your members that need to handle the work on a daily base.
  • Team: Will have your members applied to a team. So when you work with dedicated teams you can send a task to all the members of the team. You can also apply a sub-team (also called ‘subunit’) to a team as you might have seen in the identity homepage. When you have a team of ‘Developers’, ‘Testers’ and ‘Deployers’ you can send something nice to the whole ‘team’.
  • Role: When you have roles like ‘Managers’, ‘Administrators’ or ‘Identity User’ you can apply the members from the ‘User manager’ artifact in design-time

It looks to me like ‘Role’ is the oldest of all three where ‘Team’ and ‘Worklist’ where introduces with the integration of the Identity package!

But again…When to use what?

Well, it depends on your implementation, what terminology you use within the organization/solution and where you want to ‘administer’ the member applicability (in the identity homepage or in design time) . All 3 serve a way to handle a task within a group of people where to send that task to! Yes…a ‘Group’ of people…So that ‘All Groups’ list in the identity homepage might not be that wrong after all!?

Now the other questions?

  • How do we get tasks in these boxes/categories for our beloved end-users?
    • Well…I think it’s covered in the post!
  • What is the difference between roles- and teams-tasks as it sounds for me the same?…we’ll see!
    • It’s just explained…It all depends…
  • And what is a worklist? Is it a queue type of thing?
    • Looks like you can use it indeed as a queue thing
  • What will happen on a ‘groups’ type of tasks (like teams / worklists) when it’s picked up by multiple users at the same time?
    • It’s tested!…The screen got an update, but the message is not that fancy!
  • Is there a way to configure that all users from a group need to finish the task or only 1 user from the group (or maybe even a percentage of the group)?
    • Looks like this is a missing feature?…If anybody has an idea you can update me in the comments, but as far as I could find it, it’s not possible as we could only claim the task with 1 user, and the other user gets an error message.

Ohhww mama…this is it…time to give it a ‘DONE’! We learned about ‘tasks’ in this post and how we can send them to different users and even to groups of users called Teams. What else?

  • ‘Organizational Unit’ is the new terminology for a ‘Team’
  • An ‘OTDS’ role lands in the ‘All Groups’ on the identity homepage and in the back-end it’s just an external ‘Functional Role’!? Just to make the complex simple…Hooray…Or maybe I did something wrong!?
  • There is a requirement to add an ‘Identity User’ role on a security building block to let the solution land in runtime correctly

In the future you’ll see that some ‘Analyst’ asks you to implement a group type of inbox!? Well, now you know how to blow off his/her mind! Time for week-end…I see you in the next one…

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