Forms your crew will actually fill in.
Putting a paper form on a phone does not settle the questions that make it useful. The person filling it out needs to know which form applies, what each question means and whether the record was submitted. Start with that path, then configure the fields and review around the work.
Make the first choice clear
An inspection begins before the first answer. Someone has to open the right site and choose the right form. If the titles are unclear, the record can start with the wrong context even when the answers are careful. During setup, agree what each form is for and where people should go to find it.
Panora provides site form pages and configured templates for field processes such as inspections and job hazard analyses. The available forms depend on the account's enabled modules and templates. The site access path also needs setup. Crew members open the form in a browser on their phone.
Use the pilot to follow the actual entry path with the people doing the work. Check the site name, form name and access instructions. If the team also uses public Sheets intake, treat that as a separate configuration decision: Sheets public forms default off and need setup. Enabling Sheets beta does not automatically publish every tracker as an intake form.
Ask about the work in front of the crew
A useful inspection question gives the person a clear subject to observe. Compare Equipment checked with a prompt that names the equipment or condition your process needs recorded. The precise wording belongs to your workflow. The point of the setup review is to confirm that the person filling the form and the person reading it later understand the same question.
Panora's form engine renders configured sections and fields, including text, choices, dates and other supported field types. Required answers and stop rules depend on the template. A stop rule evaluates the answers entered against the rule configured for that form. It does not inspect the work area, decide that a task is safe or replace the people responsible for the assessment.
Supporting photos also depend on configuration. Photo questions are omitted when the template's photo setting is off. Decide whether photography is appropriate for the work and agree the setup before expecting a camera field to appear. A form should reflect the process the team has approved, including the evidence it is allowed to collect.
Read the record before submitting it
The review screen brings the entered answers together and provides an Edit control for each section. Use that moment to read the record as another person would. Check that the description identifies the place or equipment, that choices reflect the observation and that the next reviewer will not need to guess what a short answer means.
Signatures follow the configured form. A template with a signature field can collect a name and drawn signature on the phone. Forms without a signature field ask for the submitter's name without presenting it as a signature. Some configured forms support multiple signatures. Do not assume every form asks the same people to sign or has the same completion requirements.
A drawn mark does not improve an unclear observation. The useful review happens in the answers as well as the signing step. Before submission, correct wording that only the writer understands and check that the record describes what was observed. Your team's process determines what the signer is confirming; the presence of a pad is not an independent approval of the work.
The crew needs to know whether the record is saved on the phone or submitted for review.
Keep a draft separate from a submitted record
Panora can save local answer drafts on the device, subject to browser storage and the form's version. A local draft lets someone return to work in progress on that device. It is not a shared submission. If the template changes, an older draft may no longer match the form, so the product does not silently treat old answers as answers to a different version.
Submitting requires a connection. When the attempt has not succeeded, the form keeps that state visible and provides a way to try again. Read the result before putting the phone away. An answer visible on the screen, a completed signature or a saved local draft does not establish that the server has received the record.
Build that distinction into the pilot. Have the person filling the form explain what the current message means and what they would do next. Agree how the crew should handle an unavailable connection under your procedures. Do not make the rollout depend on an assumption that every page, attachment and submission will work offline in every location.
Finish the pilot with the person who reads it
The field experience is only part of the process. After a successful submission, authorized workspace users can review the filed record and download its PDF. Include that reader in the pilot. Ask whether the answers provide enough context to review the inspection and whether the record output contains the information the team expected.
Choose a familiar inspection and follow it from entry to the filed result. Notice unclear labels, repeated questions and answers that need explanation. Record those observations for the setup review instead of assuming a longer form will solve them. The implementation conversation is where the team agrees the modules, forms, access and record outputs it needs.
If the inspection identifies work to resolve, decide who will carry it forward. Do not assume that submitting any form automatically creates a finding or assigns an owner. Where the team uses the safety dashboard, its finding record can hold an owner, actions and a verification note. Agree the handoff and check it in the pilot so the concern reaches the person responsible.
The practical test is whether the crew can explain the path without someone standing beside them: open the intended form, enter the observation, review it and confirm submission. Then ask the reviewer to explain the result. A clear record should make sense at both ends of that handoff.