Is it possible to invoke multi-step submission workflow using either Webform or Entityform? Here is the scenario of workflows:

  • An employee submits the form
    • Superviser gets notification, after reviewing the form, he either approves it or denies the request on the same submission.
    • If approved, an email notification gets sent out to Director who in turn approves or disapproves the same submission.
  • If denied by supervisor, an email gets sent to an employee.

This scenario involves submissions by multiple roles to the same request. I could hide approval fields to employee role, but how would one access webform approval field component via rules for notification purposes? How would I freeze form state?

Should I rather use entityforms since every form component is exposed? As a last resort, I might implement my own solution using forms_api. But I would like to know first if it is possible using webform or entityforms.

  • I imagine since EntityForms is just a basic Drupal content type that the Workbench module can do all this for you. – tenken Jul 7 '15 at 15:54
up vote 9 down vote accepted

Implementing this workflow is possible by using a combination of these modules (and regular content types, no need for something like "webforms"):

Refer to my answer in the question about "How can I allow anonymous visitors to submit content?" for examples (and more details) about how to use these 4 modules together (this question here seems like a variation of that question).

Below are some details to implement your workflow with a similar approach:

An employee submits the form

Employee create a node of content type (say) "Request" (Use Content Access to finetune all sorts of permissions about "which role is allowed to create such types, if you have multiple types of requests you just extend to multipple content types).

Supervisor gets notification, after reviewing the form, he either approves it or denies the request on the same submission.

  • Use Rules to "send an eMail" (= action) to Supervisor "After content of type 'Request' gets saved" (= event). In the (custom) eMail for the Supervisor, include all relevant details about the Request (depending on the various data that are available to Rules). Such as an URL of the node to be reviewed.

  • To ensure the Requestor cannot change the Request data (while the review process is outstanding), add an extra action to the same (previous) rule which updates the access to the Request (to make it read only for requestor).

  • Use the Flag module to enable the Supervisor(s) to mark the submitted node with flags such as 'Approved (by Supervisor)' or 'Denied (by Supervisor)' (Rejected?). The permission to set these flags is limited to the Supervisor(s).

If approved, an email notification gets sent out to Director who in turn approves or disapproves the same submission.

  • Use Rules (again) so that "After a node gets flagged with 'Approved (by Supervisor)'" (= event), it causes a similar "send an eMail" (= action) to Director occurs. In the (custom) eMail for the director, include all relevant details about the Request (depending on the various data that are available to Rules). Such as an URL of the node to be reviewed.

  • Use the Flag module (again) to enable the Director to mark the submitted node with flags such as 'Approved (by Director)' or 'Denied (by Director)'. The permission to set these flags is limited to the Director.

  • Use Rules to "send an eMail" (= action) to Requestor "After content of type 'Request' gets flagged as denied (by Director)" (= event).

If denied by supervisor, an email gets sent to an employee.

  • Use Rules to "send an eMail" (= action) to Requestor "After content of type 'Request' gets flagged as denied (by Supervisor)" (= event).

So just some basic Rules/Flag stuff ...

It does not (yet) include anything related to Node Convert. This module only needs to be added to this mix if you want to further refine the above with specific "fields" that some of the workflow participants should not "see" at all (to avoid you'd have to use "field permissions", which could be an alternative to that.

Possible enhancements

Form Block

I've no experience with the Form Block module. On its project page it says "Enables the presentation of user registration, site wide contact, or node creation forms in blocks. This is particularly useful for including forms on panels.".

It seems to me that if you're using panels then there is possibly some added value when using this module. However, I'm not convinced (yet) about the real added value of this module.

There are a few things though that seem to me like red flags (= I'd think twice before using that module):

  • Where is the documentation?

    Apart from what it says on the project page, there is (a) no community documentation (at least not linked to from the project page) and (b) some readme.txt that comes with the module, but with no "real" content.

  • Where is the D7 release?

    There is an official release available for D6. But a D7 version only exists as an alfa 1, which is over a year old. And then there is a D8 version in beta status already. Not sure what is coming up in D8, but for D7 there seems to be something wrong. Is there ever going to be an official D7 version? Nevertheless, looking at the usage statistics there are a lot of D7 sites. Close to 10K reported installs for that D7-alfa version. 10K sites using the modules can't be wrong, so it must be something like "that alfa1 version is virtually an official release that should be tagged like so".

The above bullets are just a few of the criteria I often use for deciding on contributed modules. Refer to the community documentation about Maintenance Scorecards for more details. Here is the intro about it (from that page):

... contains a list of 23 criteria (=28-5) that might help to evaluate the maintenance and support of contributed modules. Below is an attempt to apply those criteria to each of the native charting modules ...

Obvious, these scorecards are related to "charting modules", but the same criteria are applicable, IMHO, wheneven you need to decide between multiple modules.

Bean

Maybe consider adding another module in the area of Blocks, by looking at the Bean module. Here is a quote about its project page:

Think of a Bean as a method to provide new types (compared to node this would be a content type) which then provides an add content interface to create as many blocks as you require (see screenshot below). The bean content can then be placed around the site just like any other block.

Combined with the options available for granting the appropriate Bean permissions, it should give you a lot of flexibility about how exactly you want to use this (great) module in your specific case. As a bonus, the Bean module also works great in combination with the UUID and UUID Features Integration modules. On top of that, after you become familiar with the Bean module, you might find other cases in your site where you also want to use the Bean module (which somehow compensates the fact that you need to add another module).

Video tutorials

If you're not familiar with Rules, checkout the video tutorials Learn the Rules framework. And/or the similar set of 8 video tutorials about the Flag module.

The video tutorial Drupal Bean module tutorial - using Bean Admin UI provides a great introduction to really understand the power of the Bean module, and the kind of things you can do with it (by only using site building techniques, no custom coding involved). It also shows how the Bean module transforms Drupal blocks into fieldable entities.

  • 1
    Interesting home grown approach! – tenken Jul 7 '15 at 15:54
  • 1
    This is very straightforward! The only concern I have with this approach is user experience. For employee at least, it would be more of content/add process, not a straightforward form (as it would have been in webforms). I will try the suggested approach and mark the question accordingly. Thank you. – JT-Drupal Jul 7 '15 at 18:30
  • Thx for feedback. Yes this would be content/add process, but with the power that "Rules" (and "Flag") adds, you could also automate (and enforce!) quite a few things. Hang o a bit and I'll extend my answer AbitMORE about what I mean with that ... – Pierre.Vriens Jul 7 '15 at 18:35
  • 1
    Pierre, it definitely worked. Thanks for suggesting this idea. I am using form_block module to improve user experience and adding the form part only. Now it is like a webform but more powerful. – JT-Drupal Jul 10 '15 at 14:44
  • 1
    Can you please include drupal.org/project/formblock in your answer so it helps other people too? :) – JT-Drupal Jul 10 '15 at 14:45

Your Answer

 
discard

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.