Advanced workflow-like behaviour: multiple manual approval steps and modifying the request during approval

Automate
#1

I would like to implement a complex VM provisioning approval process with multiple manual approve steps.

An example scenario is this: Alex requests a new VM, thereby a pending approval is created and handed over to Ben, who edits the request and assigns an IP address for the VM. Then Ben approves the request, at wich point it gets assigned to Clark for review and approval. When Clark approves, the provisioning task is created and eventually the VM will be provisioned.

I have did some research on this, and I identified two possible ways to achieve this scenario:

  1. By catching the request approval event from automate, so that I set the request state back to “Pending” and assign the approval request to a second approver after the first approval has completed. Then after the second approval, let the approval event propagate so that the task is created.

  2. (Hack) Instead of directly provisioning the VM, create a service catalog item for each step in the process (step 1: “VM Provision”, step 2: “Assign IP address”), and implement the workflow by modifying the service provisioning state machine, so that after step 1. has been approved, automatically create a request for the step 2. catalog item (instead of provisioning the VM). Then, after the step 2. catalog item has been approved, provision the VM.

I understand that both of these methods are merely workarounds at best, not real solutions. But unfortunately I couldn’t get even these workarounds working.

With the first approach, I have hit a wall when I was trying to access the “approvals” property (relation) of the “miqProvisionRequest” object. I wanted to create and add a new approval object to the provision request, but it turned out that I can’t access the approvals relationship via DRuby. So it looks like it’s a dead end.

With the second approach, I was able to imitate the workflow behaviour, but then I saw that it is not possible for an approver to modify the request object in case of a catalog item request, as it is with VM provisioning requests. (There is an “Edit” button in the VM provisioning approval screen, but there is no such button in case of service provisioning requests). This way I am unable to implement the scenario where Ben manually enters the IP address of the VM. Again, a dead end.

So my questions are:

  1. Is either one of the aforementioned approaches doable? If yes, how can I get through the problems described above?
  2. If not, is there any way to implement this functionality with CloudForms alone, without integrating with an external workflow solution?

Thanks,
Miklos

#2

@gtanzillo can you review this question from @Miklos_Balazs and forward to another SME if necessary.

#3

Hi Miklos

Multi-level approval is often requested, but at the moment it’s quite difficult to achieve from Automate (i.e. without hacking the back-end Rails code). Your step 2 isn’t working because the service provision state machine runs in task context; the request has already been approved.

Something to consider might be to look at the decision-making process that your first approver (Ben) makes, and to see if you can convert his manual algorithm into an Automate algorithm. Under what circumstances would Ben not grant the request? What is his procedure for allocating an IP address? Sometimes you can add this kind of logic into an intelligent service dialog, and only present your user with provisioning options that would pass this first level of approval anyway.

Hope this helps,
pemcg

#4

Hi Peter,

Unfortunately automating the logic of the decision-making process is not enough in our case, as we have an explicit requirement to be able to do multi-level manual approvals in general.

We have been discussing this with my colleagues, and we decided that we might make an effort to implement (or to take part in implementing) a general solution for this and upstream it for the community, given that we get some architectural guidelines to make sure that we end up with a solution that complies with the general design of ManageIQ.

From what I learned so far, I see two main directions to start with:

  1. Since the underlying data model is already prepared to handle multiple approval steps per request, it should not require substantial effort to enhance the frontend to make use of this capability. I think that this can be achieved just by exposing the underlying relations through $evm, and by a few additional UI enhancements.

  2. This might be far-fetched (and I’m just getting to know the overall architecture), but wouldn’t it make sense to have a way of representing human tasks in the automate model? I imagine a solution by which one could create a “HumanServiceRequest” from the automate model which in turn would generate a pending approval with a custom dialog. And after approving, the task context of this HumanServiceRequest would represent the completion of the human task by emitting an event in the automation engine. This would make it possible to add human task interactions in the automation workflows.

Please give us some guidelines so can we make a valuable contribution regarding this.

Regards,
Miklos

#5

Hello @Miklos_Balazs,

any progress on this? I found something Peter wrote, had no chance to take a closer look yet: https://github.com/pemcg/multi-level-approval

thx

1 Like
#6

Any progress on this?

#7

Maybe this? https://github.com/ManageIQ/approval-api
No further insight.

#8

Any updates on this? Even a simple executer-approver flow would be very useful for auditing purposes.