The cheaters guide to Case Management framework

I’ve written about OutSystems Case Management framework before, trying to get the basics in place for everyone to understand how to work with it. But I’ve got a confession to make: When I build a Case Management framework implementation I always cheat.

I tend to start with a Workflow Builder application and extend on it, rather than building it from scratch.

So today I present to you: The Cheaters guide to Case Management!

In order to understand how to ‘ hack’ you workflow builder applications to become your highly customized product, you need to understand the Workflow Builder applications structure.

Now your work builder process comes with 5 modules, but you don’t need to care about all of them!

Let’s discuss them all briefly:

• <WBNameAPP> : (screens) this is the one module without any underscores, and it contains your UI. You care about this one, as you might want to use these screens to extend the capabilities offered to users. Now adding UI does not necessarily mean dealing with this module, but it is an option. So remember this one.
• _Config: (configuration) this one honestly doesn’t come up much in my experience. All you need to know about it is that this is where the roles are stored and that it offers some functionality for assigning tasks to groups. Just ignore it for now.
• _CS:(core services) this one you might need to use if you want to do more advanced extensions on your Case Management framework, as this is the place where you set up your metadata. So if you want to add an additional status or email template, you will have to do so here. Additionally you will need to import the static entities from this module if you want to easily interact with the case management framework in other modules. Last but not least, this is where your main entity is living.
• _Th:(theme) this is your theme (e.g. app CSS style sheet), and so unless you want to do some far-reaching style changes that affect the whole app, easily ignored. My approach to CSS is that if you don’t threaten it, it won’t threaten you, so give it a wide berth.
• _WF: (workflow) This is the one where your processes live! As such it is to me the most exciting, and definitely the module I tend to change the most in. Want to add automatic steps? Slightly alter assign methods? Add additional conditions, or spin up entire different subprocesses? This is where it’s at!

Now that you have a basic understanding of the application structure, let’s talk extension methods. There is two approaches to extending Workflow Builder applications in Service Studio:
Invasive and non-Invasive. These are not official terms btw, they just describe how I feel about them.
The Invasive method is a little bit like a parasite: you enter the application, change it and take over control of it. Workflow Builder loses all control of the application, and you own it now.

Taking ownership of the application.

The non-invasive method is slightly more polite: you allow Workflow Builder to maintain control and you simply interface with those methods it has provided as public actions.

As per usual being polite doesn’t get you anywhere near as far as ruthlessly taking control of the situation, but it does win you more friends if the Workflow Builder application is made and controlled by another party.

Alright, enough talk, let’s get hacking!

And because politeness is still valued, let us start with a non-invasive extension on a workflow builder application.

Non-Invasive extension

This strategy works best for providing additional UI on top of the application, but other small changes can also be achieved through this method. A great example of this approach is adding a mobile frontend onto the workflow. Mobile applications can allow people who are regularly in non-office environments to achieve things efficiently that otherwise would be difficult. Imagine using a barcode scanner to scan a machine in a factory to report a defect with all necessary context information, and minimum amount of typing.

So how do you build a (mobile) application on top of a Workflow Builder app? That depends on what you want it to do of course! I will focus in this example on starting a request, but you could also want to show the information of a case or enable users to execute assigned tasks in the app.
I’m hoping that I will cover the latter two scenarios sufficiently in the invasive method for you to be able to extrapolate how this can be done non-invasively as well. And so you will just focus on submitting a case from the mobile interface, without invading the Workflow builder app.

What you’ll need:

• A mobile app, that requires the user to be signed in
• Users who have the <WBAppName>Requester Role
• The <WBAppName>_Create action
• A CaseFiles list variable in the place where you want to use the aforementioned create action.

How to do it:

1. Open up your mobile app, go to the place where you have built your case submit logic. This case should (in my opinion) be build with the convenience of the user in mind, and will therefore probably not have the data in exactly the right way for the case you want to submit. That is fine. You will do some mapping :-)
2. Grab your <WBAppName>_Create action, figure out the differences between the data structure in the action and the data in your screen. Start building the logic to translate your available information into the correct structure for your case. Here are some specific things you’ll need to know about this action:
3. The CaseFile list structure needs to be filled. That is to say: you don’t have to add any files, you just need to have a variable with this structure and pass it on to the Create Action.
4. The create action will only work for users who are logged in with a Requester Role, so either build your screen so that only those people can access it, or build in some exception handling for the error you’ll inevitably get when they don’t have that role. The first solution is the preferable one here, of course.
5. It might go without saying, but your CaseId is a NullIdentifier on the create action :-).
6. If you want to be all fancy, make sure to add logic where you evaluate if the user has provided a null value or not for dates and boolean values, and utilize the “SourceEmptyFields” to share that information. (You do this by setting the specific attribute to True if the actual intent is a null value, rather than the deliberate decision to set a certain boolean to false, for example.) This will ensure that the value is displayed as empty in the workflow builder app, rather than displaying the null value.
7. Test it out. And for kicks and giggles, try changing the workflow in Workflow Builder and see that it still works. How nice it is to take the polite route!

Yes, it’s really that easy. Want to watch me do this? Here is a small video of me creating and extending a workflow in a non-invasive manner using this exact method.

That is what I will leave you with, today.

In my next article you will go over to the dark-side (they have cookies!) and hack our way through Workflow Builder Apps, using the invasive method.

I am planning to discuss things like:

• adding escalations and delegations,
• setting up and using email templates,
• understanding and changing screens,
• and of course understanding and changing workflows!

Just imagine all the fun we will have!