The success of Webform is the ability of administrators to rapidly create and deploy a data gathering form and have a small number of users deal with a large number of submissions in various ways, either manually or in some automated fashion as we demonstrated with custom actions in Chapter 10,Creating Submission Actions.

Webform is a little limited in offering ways to present the gathered data, though. We have capability to view the submitted data as an online table, or we may page through the submissions one at a time. The downside of this, in terms of presentation, is that we are unable to define what the outputs should look like by limiting which fields should be part of the display, the sequence in which the fields should appear, and so on.

Clearly it would be beneficial if we had the facility to define customized data listings without having to fiddle with Webform access permissions for various roles and users. In this way we could provide partial data listings to users who have no backend Webform permissions.

One of the defining characteristics of FOSS (Free and Open Source Software) in general, and the Drupal ecosystem in particular, is choice. Whatever else we may lack, we will very seldom find ourselves lacking for options. In this chapter we are going to take a look at two different methods of creating custom Webform reports. On the face of it this may seem somewhat redundant, but the two approaches differ as night from day, each with its own pros and cons.

Once we have examined methods for extracting and presenting data from submissions, we shall take a look at a module which enables us to track changes made to Webform submissions after they were originally submitted.