Permit to work on the job, not in a binder.
A permit should stay close to the work it describes. The crew needs the right questions at the site, and the person reviewing the work needs a readable record afterward. Moving the form onto a phone helps with that handoff, provided everyone understands what submitting the form does and what still requires a human decision.
Start with the permit your team actually uses
Panora's Permits area lists active permit templates available to the account. Each entry shows its version, whether stop rules are armed or advisory, and links to the recorded submissions. A permit is a configured form within the forms capability. The questions and checks depend on that template, rather than a universal permit that fits every job.
Begin with a familiar permit and the people who use it. Work through the purpose of each question, the information needed before work starts and the person responsible for review. Keep the distinction between a required answer and a safety decision clear. Making a box mandatory can ensure an answer is entered; it cannot ensure the answer describes conditions accurately.
Treat this as part of the implementation review. Confirm the enabled capability, site, template and access arrangements before handing a link to the crew. A permit that appears in a manager's workspace is not, by that fact alone, ready for field use. The people doing the work should try the complete path during the pilot.
What the crew sees at the site
Configured field forms open through a site entry point on a phone. Site-code access lets a crew use the form without a manager login. The permit list provides a separate opening link for each available site. Those links depend on the site's enabled access and code, so setup is part of the workflow rather than something a printed link can replace.
The crew works through the configured questions, reviews the answers and completes the signature fields the template requires. Forms that do not ask for a signature use a submitter name for attribution. A typed name on such a record should not be described as a signature that somebody drew. Read the actual form when explaining what the crew will be asked to do.
Use a specific job in the pilot. Ask the crew to find the form, identify the site and explain any question they cannot answer yet. Watch for wording that makes sense at a desk but is unclear beside the work. That review is advice for implementing the process, not an automatic product check of whether the job is ready.
Know which answers can stop submission
When a template has armed stop rules, Panora checks the submitted answers against those configured rules. A failed check can refuse the submission and show the crew which condition needs attention. The permit list distinguishes this from an advisory template, which records the answers without those rules blocking issue. Do not assume every permit has the same checks.
The system checks the values entered. It does not measure the site, observe the work or establish that a condition is safe. Your team remains responsible for assessing conditions and following its procedures. If a response is refused, address the underlying condition through that process. Changing an answer solely to get past a message would leave a misleading record.
As a practical setup exercise, review an acceptable example, an incomplete example and an example that should be stopped. Agree what each result means and what the crew should do next. Use demonstration answers during the pilot. The useful outcome is a shared understanding of the configured limits and the people responsible for resolving a problem.
A submitted form is a record. Permission to proceed still needs a clearly understood process.
What the reviewer can inspect
Authorized reviewers can open a recorded submission to see the form name, site, submitter and received time. The record displays the stored answers with the wording captured for those answers. It also shows the form version and recorded signature information. That gives the reviewer context for reading what was filed, even when a template changes later.
The submission view includes a PDF download and printing. Use those outputs when the review needs a filed copy, and check the actual record rather than relying on a message that a form was completed. An approver following your procedure can inspect these details; the existence of a submitted record does not establish that every required operational approval has happened.
Before rollout, agree who reviews which permits and how the crew learns the outcome. If your process calls for particular approval fields, confirm them in the configured template and walk through them with the responsible people. Do not infer an automatic approval chain from the presence of signatures. The agreed procedure should explain who has authority and what action they take.
Finish the handoff before expanding it
A saved answer draft is not a submitted permit. Local drafts can keep answers on the device, but submission requires a connection so the server can evaluate the form and receive the record. If an attempt does not land, the crew should follow the visible result and the site's agreed fallback. Do not treat an offline draft as authorization to work.
End the pilot by asking someone who was not involved in filling the form to read the resulting record. Can they identify the job context, understand the answers and explain what still needs review? Then ask the crew to explain what they would do if conditions changed. These are checks of the working process around the form.
Start with a bounded permit workflow and resolve its unclear handoffs before adding more templates. A phone form is useful when the crew can reach it and the next person can understand it. The same principle applies after a safety finding is completed: keep enough context that someone else can explain what happened and why the next step was taken.