Digital Walk-Around Inspections Part I - How to Build an Auditing App

This article is the first part of our two-part series on how to build an auditing app with Peakboard. In this article, we explain the architecture of an auditing app, including how the audit definition and audit data tables work.

In the second part of this series, we discuss how to build and operate an auditing app.

Note that the examples we use in these articles are simple and may not satisfy all the requirements of a real-world audit and visual walk-around. But the basic process is the same, and you can easily customize the auditing app to suit your needs.

What does an audit look like?

This is what an audit, or “digital walk-around,” looks like:

1. The user opens an auditing app on their tablet.
2. The app presents the user with a list of possible audits.
3. The user selects the audit they wish to perform.
4. The app gives the user step-by-step instructions for how to perform the audit. For each step:
   1. The user follows the instructions for that step.
   2. If the step requires information from the user, the user enters that information into the app.
   3. The user marks the step as done.
   4. The user moves on to the next step.
5. The audit is finished. The app saves the results into a document and persists them.

Example audit

The following is an example of an audit. It tells the user how to perform a safety check for a CNC machine. Steps 4 and 5 require the user to enter information into the app.

1. Welcome the user and explain the purpose of the audit.

2. Tell the user to inspect both emergency stops.

3. Tell the user to test the safety door to make sure it works properly.

4. Tell the user to visually inspect the milling head, and record their observations in the app.

5. Tell the user the inspect the lubricant canister, and record the amount of remaining lubricant in the app.

How to define audits

Audits are defined by two tables: AuditTemplateHeader and AuditTemplateItem. These tables specify the structure and content of every audit.

In our example, we used Peakboard Hub to store these tables. But you can any storage solution that is supported by Peakboard.

The AuditTemplateHeader table

The AuditTemplateHeader table is a list of all the audits. It contains one row for each audit. Each row has two columns:

The AuditTemplateItem table

The AuditTemplateItem table defines the steps of all the audits. Each row represents a single step in an audit. The following is an overview of all the columns in this table.

Audit name

AuditName specifies the audit that the step belongs to. Remember that the AuditTemplateItem table contains the steps for all the audits. This column tells Peakboard which steps belong to which audits.

The AuditName column must match the Name column of the corresponding audit in the AuditTemplateHeader table. Notice that CNCSA1 also appears in our example AuditTemplateHeader table.

Step number

StepNo specifies the number of the step. So the first step has StepNo 0, the second step has StepNo 1, etc. This column tells Peakboard how to order the steps of each audit.

Layout

Layout specifies the visual layout of the step. Our example CNC safety audit from before uses three different layouts:

Variables

The columns Var01 to Var05 are variable columns that specify the data for each step. Here’s an explanation of how they work.

For every layout:

• Var01 is the title of the step.
• Var02 is the text instructions of the step.

If the layout is FT01 or ENTRY01:

• Var03 is the URL of an image that appears in the step.

If the layout is CHOICE01:

• Var03, Var04, and Var05 are the three multiple choice options.

It’s important to understand how the layout and variables work, because they are central to our data structure.

The three layouts mentioned above are what our example uses. But in the real world, you might use other layouts, or more layouts. It’s even possible to use 10 or 15 variables, if necessary. It all depends on your specific use case.

Audit data storage

When an audit is performed, the data for that audit run is stored in two tables: AuditHeader and AuditItem. These tables store the data for every audit run.

The AuditHeader table

The AuditHeader table is a list of every audit run. It contains one row for each audit run.

Here’s an overview of the columns:

The AuditItem table

The AuditItem table is a list of every step in every audit run. It contains one row for each step, for each audit run.

Here’s an overview of the columns:

Conclusion

To build an audit application, you need to understand the architecture of the underlying data structure: both the audit definition and audit data tables. That’s what we discussed in this article. In the second part of this two-part series, we will explain how to build the actual application and run the audit.