Workflows

IGA offers many actions that can be executed for an object. You might set attributes, change lifecycle state, assign roles and so on. Sometimes you want to pack several actions into a single business, possibly with some conditions and branching, and execute it as a whole.

Apparent benefits of such defined workflow is that is always executed in a consistent manner. Operators might easily execute all actions manually but that give unnecesary space for human error.

Another benefit might be to execute the workflow for several users at the same time, which might be used by IGA administrators for their routine configuration tasks.

Having manually triggered workflows are fine, but IGA is mostly about automation. In a lot of cases you want to define additional action that should trigger on certain occasion.

Main benefit of triggered actions is naturally extending actions that are already happening to achieve your business use-cases.

Human element in workflows are typically the approvals. Some actions can be automatically denied, but in real environment it might be practically impossible to automate complex decision processes. Therefore, some actions might require approval before they can be executed.

Sometimes you need to prepare an easy way for other users to interact with the IGA. One of the options, that often comes into mind is creating a custom form where users fills in all data, and then it is automatically processed.

This scenario might be more complex in practice than initially perceived. In our example, it would be better if the form would offer input field for validity when you select external employee type. Therefore, this simple scenario would in practice typically need way more interactivity and would be closer to the complex workflows.

The last items covers anything that you can imagine. Capturing inputs from user to start the workflow, passing it to another user for the next steps in the workflow, whis might be as simple as approval but also something more complex. Then the workflow might branch based on the current progress or start executing some actions and continue with another actions or another human guided step. Basically any complex scenario combining humans and machine actions.

In practise this is implemented by workflows engines that are able to define complex workflows and typically can execute them over multiple systems either executing actions in them or reading the data required for futher processing. Workflows engines are very potent tools for implementing company-wide processes.

Addressing the first requirement for predefined actions, midPoint offers the option to define custom actions that can be executed on demand. It’s based on Actions, that can be encapsulated in Scripting Tasks. It gives you easy way to create custom actions using predefined options, or you can prepare a script that can contain complex logic.

The tasks can be integrated as custom actions to midPoint GUI make it easier for non-technical users to execute them. See Custom actions in GUI for details.

Policy rules allows you to define policies that can be checked or enforced. Policies also might have conditions when they are triggered. That allow you to defined policy that will enforce certain actions and be triggered on custom conditions. Thanks to this, midPoint can cover the second type of workflows (triggered actions).

The difference between policies and traditional workflow engines is the policy will trigger anytime the defined trigger occurs. Well-defined policies will help you maintain consistency in the IGA system. For example, if you define a policy reaction on employee leaving the company the policy will trigger regardless if the event is propageted from HR system or if it is a manually triggered action. Instead of designing complex workflows and carefully considering all possible interactions, midPoint’s policy rules gives you tool, that behaves consistently in all situations.

As we covered in workflow type number 3., the typical human interaction element are approvals during the workflow execution. MidPoint is using aforementioned policy rules to start the approval process. That gives you enormous flexibility in defining what should be approved.

Furthermore, it also maintains consistency. Policy rules by default doesn’t differentiate how the event started. If you need something to be approved before execution, you can relay on policy rules, regardless if the event was triggered by action in GUI, synchronization process, another workflow or something else.

As usual, midPoint gives you huge flexibility in defining all required details, like how the approvals will be selected or if multistage approvals are needed. See approvals documentation for details.

The last two types of workflows are covering form based actions and workflow engines. MidPoint is following the design rule of focusing on single purpose and master it rather than being universal bloated tool for everything. For that reasons it doesn’t implement complex workflows engine functionality that would anyway require integration with other systems and applications beyond standard IGA integration that midPoint offers. But midPoint offers an option to be integrated with external workflows engines.

For the same reasons midPoint currently don’t offer form based custom actions described above. We are considering them very close to the full workflow engines capabilities. So if you estimate you will need just a few simple forms, you will most likely soon need more options and the best approach might be to consider full workflow engine system from the beginning.

The best results are typically achieved by combining more features together. MidPoint strength is in maintaining consistency regardless how complicated configuration you will define. With that in mind you can combine all described options as you like, including the external workflow engine integration. That will give you enough flexibility to achieve any workflow that you might need. For most use cases except the very complex ones, the native capabilities of midPoint should be sufficient.