How to implement a multi step approval with webforms/entityforms based on form components? 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.
Implementing this workflow is possible by using a combination of these modules (and regular content types, no need for something like "webforms"):


Rules.
Node Convert.
Flag.
Content Access.


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.