The Public Works Permit is dynamically built from various pieces of data in the Public Works (PW) Tracking record type. For this reason, it is important to understand the data requirements for the permit to be successfully generated.
In the intake form of the PW Tracking record type, there is a 'requirement' to select at least ONE service area checkbox. However, this requirement is only enforced at issuance; you cannot issue the permit via Workflow until this requirement is met. The three service areas provided for in the PW Module, displayed on the "01 General Info" tab, include: Sidewalk/Driveway/Curbcut, Right-of-Way, and Erosion/Sediment Control - a PW permit can include all three or even just two, but minimally requires at least ONE be selected ultimately.
By design it is expected, but not required, that application specific info (ASI) on the corresponding tab(s) would also be filled in and completed, i.e. Right-of-Way is checked as a service area included in the permit application, so ASI in the actual "03 Right of Way" tab would also be filled in accordingly.
Once plan review is completed via Workflow, by design it is expected, however again not required, that Conditions of Approval would be added to the record via the Conditions of Approval tab indicating what specifically is being approved for this specific application and as per what locally-defined specs or requirements.
Once the permit is issued via Workflow, the checkbox requirement is enforced and the PW Permit report is automatically generated. This particular permit report is a 'smart' report, it looks at what service area checkbox(es) where checked and then pulls the corresponding ASI for each. If you did not fill in the corresponding ASI tab(s), the permit report will still display all the ASI for that service area(s) indicating 'none indicated' for each item that was not filled in.
The Conditions of Approval is intended to be the body of the PW Permit report, if you did not indicate any Conditions of Approval for Public Works - the generated permit report will be somewhat abbreviated with the main Conditions of Approval section indicating 'none indicated', which may not be ideal depending on what the application was specifically for. You may have some business cases where no Conditions of Approval are called for/applicable, and this is fine - that's why the PW Tracking record type and the PW Permit report were built with this level of flexibility.
In summary, the PW Permit was built as a 'smart' report in the above ways given most participating PW agencies indicated that they approve the specific permit application as per locally-defined development standards which is why the ASI and the Conditions of Approval are setup to be the primary components of the PW Permit.