How to Build a Conditional Production and QC Form for Window Coverings

‍A step-by-step guide to designing smart, routing-driven quality control forms in Clappia: from metadata and department routing through to inspection outcomes, measurement tolerances, evidence capture, and workflow automation.

Why Most Production Forms Fall Apart in Practice

The idea behind a production form is straightforward. Operators record what they did, what they checked, and whether it passed. The reality on most shop floors is messier. A single generic form gets used for every product type, so operators wade through fields that do not apply to their task. Inspection outcomes get recorded without any supporting evidence. Measurements are noted in a comments box rather than structured fields. And when a product is returned weeks later, the record is too sparse to tell you what actually happened during production.

The fix is not a longer form. It is a smarter one. A conditional form shows each operator only the fields relevant to their specific product and task, prompts them to capture evidence before recording an outcome, enforces measurement recording with tolerance guidance, and builds in a confirmation step that forces them to check the production ticket before starting. The result is a form that is faster for operators and far more useful for quality managers.

This article walks through exactly how to build that kind of conditional production and quality control form in Clappia, using a window covering production workflow as the working example. The principles apply equally to any manufacturing or assembly context where multiple product types move through a shared production floor.

Understanding the Form Architecture Before You Build

Before placing a single field, it helps to understand the three-layer conditional architecture that makes this kind of form work. Each layer narrows the context, so operators always see a lean, relevant set of fields rather than a form cluttered with inputs that do not apply to them.

The first layer is the top-level router. A radio button or select field that captures the department or product area acts as the master switch. Every other field in the form is controlled, directly or indirectly, by this single value.

The second layer is the subtask select. Once a department is chosen, a product-specific select field appears with the task options relevant to that product: Inspection, Assembly, Intermediate Inspection, Repair, Packing, and so on. This subtask value then becomes the second conditional trigger.

The third layer is the contextual fields. Measurement inputs, inspection outcome selects, evidence file fields, and confirmation checkboxes all appear only when the specific combination of department and subtask requires them.

The pattern is: Department select drives Subtask select, which drives measurement fields, inspection outcomes, evidence files, and confirmation checks. Everything stays hidden until it is needed.

Step 1: Build the Metadata Section

Every submission needs a consistent set of identifying fields that tie it to a specific job, operator, and moment in time. Without this, submissions become anonymous data points with no traceability. The metadata section is typically the first section in the app and is always visible, regardless of the department chosen.

Core Metadata Fields

Add the following blocks to your first section, which you might call Customer Details or Submission Metadata:

• Barcode (Text Input block): This field captures the job or order reference that links the submission to a specific production ticket. On mobile, enable barcode scanning so operators can scan the ticket barcode rather than typing a reference manually. This eliminates transcription errors.
• Date (Date block): Set the default value to today's date. This ensures every submission is date-stamped without requiring manual entry.
• Time (Time block): Set the default value to the current time. Together with the date field, this creates a precise timestamp for the submission.
• Department (Radio Button block): This is your top-level router. List every product family and operational category your floor handles. Typical options include Rollers, Headrails, Shutters, Perfect Fit, Verticals, Wood Venetian, Night and Day, Alu Venetian, Sawroom, Packing, Dispatch, Goods Inwards, Clock In and Out, and Downtime. The value selected here drives all subsequent conditional display.

Shift and Operational Fields

Beyond the core job reference and timestamp, add the following fields to capture shift-level context:

• Clock In and Clock Out: These can be handled as options within the Department radio or as a dedicated time capture flow. Including them ensures shift boundaries are recorded alongside production data.
• Downtime (Select block): Provide a predefined list of downtime reason categories. This ensures downtime is recorded consistently and can be aggregated in reporting rather than buried in free-text notes.
• Dispatch and Dispatch Return (Select blocks): Capture the transit route or return route when a submission relates to a dispatch or return task. These fields are conditionally visible when Dispatch or Dispatch Return is selected as the Department.

For guidance on setting up Date, Time, and Radio Button blocks in Clappia, see the Clappia Help Centre.

Step 2: Configure the Department Router and Subtask Selects

With the metadata section in place, the next step is setting up the conditional logic that powers the form's routing. This is done through display conditions on each subtask select field.

How Conditional Display Works in Clappia

Clappia's display conditions allow you to show or hide any field based on the value of another field. For this form, you will create one Select block per product family and configure each one to appear only when Department equals the corresponding product name.

For example: create a Select block called Rollers Task. Set its display condition to: Department equals Rollers. This field remains hidden for every other department selection and appears only when the operator selects Rollers. Repeat this for every product family in your Department radio.

Subtask Options by Product Family

The subtask selected for each product family should list the actions that operators in that area actually perform. The table below shows example subtask options for the main product families.

Keep the subtask option labels clear and unambiguous. Operators will be selecting from this list repeatedly throughout the day, so label precision reduces selection errors.

Step 3: Add Conditional Measurement Fields with Tolerance Guidance

Measurement fields are the backbone of dimensional quality control. The key design principle is to create individual fields for each measurement dimension rather than a single notes or comments field. This makes measurements searchable, comparable across submissions, and usable for trend analysis.

Design Principles for Measurement Fields

• One field per dimension: Create separate Text Input blocks for left, right, top, bottom, and any product-specific dimensions such as tension or drop size. Do not combine measurements in a single field.
• Conditional display: Set each measurement field's display condition to show only when the relevant product and subtask combination is selected. A measurement field for Perfect Fit frame dimensions should not appear when the operator is on a Rollers task.
• Tolerance guidance in the field label: Use the field description or label to state the tolerance requirement directly. For example: 'Frame Width Left (mm) - must not exceed 1 mm from ticket dimension'. This keeps tolerance guidance in context, at the point of data entry, rather than in a separate document operators may not consult.

Example Measurement Field Sets by Product

The following examples show how measurement fields are structured for the main product families that require dimensional recording.

Clappia's Text Input block supports field-level descriptions and label customisation. See the Clappia block documentation for configuration details.

Step 4: Pair Inspection Outcome Selects with Required Evidence Fields

This is the most important structural decision in the form design, and it is the one most often overlooked. An inspection outcome recorded without photographic or video evidence is an assertion, not a verification. Making evidence capture a required step before the outcome can be finalised turns assertions into auditable records.

The Evidence-Then-Outcome Pattern

The recommended approach is to place evidence file fields immediately before the outcome select field in the form flow. This creates a natural sequence: the operator takes the photograph or video, then records the outcome. Evidence fields placed after the outcome tend to be skipped because the operator considers the task complete once the outcome is selected.

For each product inspection flow, you will need:

• One or more Image or File blocks: Each block captures a specific view (front, back, full open, detail close-up). Name each field to describe the view it should capture, so the purpose is clear to the operator.
• A Video block for operation evidence: Particularly useful for headrails and shutters, where a short clip showing the product in operation confirms smooth function in a way that a photograph cannot.
• An outcome Select block: Placed after the evidence fields. For some products, the options are simply Passed or Failed. For rollers, a more granular option set (Passed, Fabric Run Off, Wrong Size, Flawed Fabric, Squint Lathe, Wrong Fabric) provides better failure mode data.

Place evidence capture fields before the outcome select. The sequence matters: photograph first, outcome second. This single design decision significantly improves evidence compliance.

Inspection Evidence by Product Family

Making Evidence Fields Required

In Clappia, you can mark any field as required using the field's validation settings. Set each evidence file field to required within the conditions where it is visible. This means the form cannot be submitted without the photograph being attached, which enforces the evidence standard without relying on operator discipline. See Clappia validations for step-by-step instructions.

Step 5: Add Checked for Special Instructions Confirmations

Production errors driven by operators not reading the ticket before starting are one of the most common and most preventable causes of rework. A confirmation checkbox placed at the start of each task context, requiring the operator to confirm they have read and followed any special instructions, creates a simple but effective enforcement point.

Where to Place Confirmation Fields

Add a Checkbox block called Checked for Special Instructions (or similar) in each product context where inspection, assembly, or rework tasks occur. The display condition for this field should match the context it belongs to: visible when the relevant department and subtask combination is selected. Key locations include:

• Perfect Fit inspection and assembly tasks
• Roller inspection and intermediate inspection tasks
• Wood Venetian inspection and build tasks
• Vertical slat assembly and roll tasks
• Any rework or repair subtask across all product families

Set this field as required within its display condition. This prevents the operator from completing the submission without confirming the ticket check. The field value is saved with the submission, so you have a record that the confirmation was given for every job.

A Note on Placement

Place the confirmation checkbox near the top of the task-specific field group, not at the bottom. If it is at the bottom, operators may complete all the other fields and then encounter the confirmation as an afterthought. Placing it first signals that it is the starting condition for the task, not an administrative box to tick at the end.

Step 6: Build Packing Count Checks with a Discrepancy Formula

For products that involve component counting at the packing stage, a simple numeric check prevents count errors from reaching the customer. The classic example is vertical slats, where the number of slats listed on the production ticket must match the number actually packed, for both standard and PVC slat types.

Fields Required

• Slats on Ticket (Numeric Input block): The count as stated on the production ticket.
• Slats Packed (Numeric Input block): The count the operator has actually packed.
• Packing Photos (Image block): A photograph of the packed components, ideally with the ticket visible in frame.
• Discrepancy (Formula block): A calculated field that shows the difference between the two counts.

The Count Discrepancy Formula

In Clappia, add a Formula block with the following calculation:

{Slats on Ticket} - {Slats Packed}

What it uses: the Slats on Ticket numeric field and the Slats Packed numeric field.

What it does: subtracts the packed count from the ticket count.

What the operator sees: a value of zero confirms the counts match. Any non-zero value immediately flags a discrepancy that must be resolved before the submission is finalised. The formula output is saved with the submission, giving supervisors a record of whether the count check passed at the time of packing.

For PVC slat types, add a second set of fields and a second formula block following the same pattern. Clappia's Formula block documentation is available at help.clappia.com.

Step 7: Set User Access, Permissions, and Mobile Configuration

A production QC form is only useful if the right people can access it and the wrong people cannot. Clappia's role-based permission system lets you assign different levels of access to different team members without requiring any technical configuration.

Role Recommendations

• Operators: Submit permission only. Operators can fill in and submit the form but cannot edit previous submissions or access reporting dashboards.
• Supervisors: Submit and view permissions. Supervisors can review submissions from their team and monitor inspection outcomes in real time.
• Quality Managers: Full access. Quality managers can view all submissions, access analytics, export data, and manage the app configuration.

To configure access, go to the app's permission settings in Clappia and assign roles to individual users or user groups. Full documentation on user permissions in Clappia covers both individual and group-level access control.

Mobile App and Offline Mode

Clappia's mobile app, available for iOS and Android, makes the form fully functional on a smartphone or tablet on the production floor. Operators can scan barcodes using the device camera, capture inspection photographs directly from the form, and submit records without needing to return to a desktop terminal.

Importantly, Clappia supports offline mode. Submissions made when the device has no network connection are saved locally and synced automatically when connectivity is restored. This is essential for production environments where Wi-Fi coverage is patchy or unreliable in specific areas of the floor. Operators do not need to think about connectivity. They fill in the form, it saves, and the record appears in the system when the device next connects.

Step 8: Passive Logging or Active Workflow Automation?

Once the form is built and collecting data, you have a choice about how the system responds when a submission is saved. The simplest approach is passive logging: submissions are saved, data is captured, and nothing else happens automatically. This is a perfectly valid starting point and gives you a clean data set to work with before adding complexity.

The alternative is to add active workflow nodes in Clappia that trigger actions when specific conditions are met on save. The decision depends on how your QA process works and how quickly your team needs to respond to failed inspections.

Keeping Automation Passive

A passive setup triggers a simple pass node on save, which means the submission is recorded but no notifications or follow-up actions are triggered automatically. This is appropriate when:

• Your QA team reviews submissions manually on a regular cadence
• Failed inspections are handled through an existing verbal or physical escalation process
• You are in the early stages of rolling out the digital form and want to establish data quality before adding automation

Adding Active Workflow Nodes

Clappia's workflow builder allows you to add nodes that trigger on save when specific field values are present. For a production QC form, the most valuable automation nodes are:

• Failure notification: When an inspection outcome select contains a failure value (any value other than Passed), send an automated notification to the supervisor or quality manager. This can be an in-app notification, an email, or a message to a connected communication tool.
• Rework record creation: When a failure is recorded, automatically create a new submission in a rework tracking app with the job reference and failure type pre-populated. This ensures the rework task is logged and assigned without manual intervention.
• Escalation for repeated failures: If the same job reference appears in multiple failed inspection submissions, trigger an escalation notification to a senior manager. This catches systematic problems before they affect a larger batch.

Start passive. Add active workflow nodes once you have established what your most common failure types are and how quickly your team needs to respond to them.

Complete Field Reference for Each Product Flow

The table below provides a complete field reference for each product family, showing the subtask that triggers the fields, the field type, and the field purpose. Use this as a checklist when building your form.

Using Clappia Analytics to Monitor QC Outcomes

Once submissions are flowing in, Clappia's built-in analytics dashboard gives you a live view of production quality without exporting data to a separate tool. You can build charts that show inspection outcome distributions by product type, failure mode frequency over time, measurement readings against tolerance thresholds, and packing accuracy rates.

The most valuable early reports to set up are a failure rate by product family and a failure mode breakdown for rollers. These two views will quickly tell you where your QA effort should be focused and whether any systemic issues are developing. As submission volume grows, you can add trend views that show whether failure rates are improving or deteriorating over time, giving production managers an objective measure of process improvement.

Building the Form: A Final Checklist

Before you publish your conditional production and QC form, work through the following checklist to confirm the form is complete and behaves as intended.

1. Metadata section is present and all fields (Barcode, Date, Time, Department) are always visible
2. Department radio button lists all product families and operational categories
3. Each product family has a subtask Select block with a display condition tied to the Department value
4. Each subtask select option triggers the correct set of measurement, evidence, and outcome fields via conditional display
5. Measurement fields are individual text inputs per dimension, with tolerance guidance in the field label
6. Evidence file fields are placed before the outcome select field in every inspection flow
7. Evidence file fields are set as required within their display conditions
8. Each inspection flow has a specific outcome select with the appropriate pass/fail or detailed failure mode options
9. Checked for Special Instructions checkbox is present in every product context involving inspection, assembly, or rework
10. Packing count fields include a formula block that calculates the discrepancy between ticket count and packed count
11. User roles are configured so operators have submit-only access and supervisors have view access
12. The form has been tested on a mobile device in both online and offline mode
13. A decision has been made on whether to keep automation passive or add workflow nodes for failed inspection responses

Getting the conditional architecture right from the start is the difference between a form that operators actually use and one that gets abandoned in favour of paper records. A form that shows only what is relevant, requires evidence before recording outcomes, and enforces ticket checks creates a QA system that is faster for operators and far more reliable for the production managers who depend on it.

Ready to build? You can start for free at www.clappia.com. The form described in this article can be replicated using the blocks and conditions outlined above, with no coding required.