Quick answer
A structured process assigning reviewers, evidence, findings and release decisions to identified solar design revisions. Customer, professional, authority and utility approvals have distinct scopes.
What Is a Design Review Workflow?
Answer: A design review workflow assigns people, evidence and decisions to checkpoints before a solar design is used for a defined purpose. It can include self-review, peer review, professional engineering review and customer confirmation. Record the exact revision reviewed, unresolved issues and release scope. Internal approval, customer agreement, permit acceptance and utility authorization are separate decisions with different responsibilities.
A useful review is more than opening the latest file. It identifies what was examined, what remains uncertain and who can authorize the next step. Version control keeps the reviewed drawings, models and related outputs identifiable.
NASA’s configuration-management guidance describes controlling changes to baselines, distinguishing versions and maintaining consistent product information. Those are useful general engineering principles; NASA’s process is not a legal requirement or a prescribed solar approval workflow.
Reviews with Different Scopes
| Review | Responsible participant | Purpose and boundary |
|---|---|---|
| Self-review | Original designer | Check completeness, assumptions and consistency before handoff; not independent verification |
| Peer review | Assigned reviewer with suitable expertise | Challenge inputs and resolve design findings; does not replace legally required professional review |
| Professional engineering review | Appropriately qualified professional for the relevant scope | Review required structural/electrical matters; licensing, signatures and scope depend on the project and jurisdiction |
| Customer confirmation | Owner or authorized representative | Confirm agreed placement, specifications, commercial terms and stated assumptions; not technical code approval |
| Authority or utility review | Responsible authority or grid operator | Required acceptance within its own scope, separate from the team’s internal release |
There is no universal system-size threshold requiring the same reviewer or a fixed review duration. Choose internal checks according to risk and project requirements while confirming any mandatory professional or authority requirements.
What the Review Package Should Contain
Preserve the design identifier and revision, equipment selections, drawings and relevant calculations. Provide source documents for critical assumptions and mark unverified site conditions. Include the findings from a design variant comparison if alternatives remain under consideration.
For a practical solar review, consider:
- Layout and site inputs: actual roof/site boundaries, pitch, orientation, obstructions, usable area and applicable access constraints. Imagery is not proof of concealed roof condition or verified structural dimensions.
- Equipment selection: exact model, ratings, instructions and compatibility. Reconcile module count and dimensions across the layout, specifications and BOM.
- String and input checks: evaluate voltage at relevant design conditions, the operating MPPT window and applicable current limits using the exact equipment and required method.
- Electrical scope: conductor/protection design, grounding, isolation, applicable shutdown requirements and actual routing. Require qualified review rather than relying on a generic checklist.
- Structural scope: site-specific loading and attachment/racking design using applicable requirements and professional responsibilities.
- Production estimate: check weather, shade geometry, loss assumptions and output boundary. Do not use a universal US kWh/kWp range as proof of accuracy.
- Materials and constructability: reconcile the BOM, equipment access, routes and field-dependent work. Automatically extracted quantities do not settle completeness.
- Customer package: explain the actual layout, selected equipment, stated production assumptions, commercial terms and relevant limitations without presenting projections as guarantees.
PVsyst’s array-voltage sizing documentation distinguishes operating voltage checks from cold-condition open-circuit voltage limits. Its inverter-model documentation also distinguishes current-limited operation. A plausible DC/AC ratio does not replace these checks, and software defaults are not automatically the site’s required design conditions.
DOE’s PV installation and commissioning guidance addresses site, structural, equipment and commissioning considerations. Use the actual applicable product instructions and project requirements; a web checklist is not authorization to undertake live electrical testing.
Track Findings Through Closure
For each finding, record the affected document/detail, issue, evidence, severity or release consequence, assigned owner, response and disposition. Identify which revision resolves it and who checked that resolution.
A useful status sequence is open → response submitted → verified resolved, with an explicit record for an accepted exception where the responsible person is authorized to accept it. Do not equate a comment marked “done” with verified correction.
Maintain scope-specific release states, such as released for customer review, released for permit submission, released for purchasing or released for construction. Determine which decisions are required for the actual project. A customer-approved layout is not an approved electrical installation, and permit issuance is not utility permission to operate.
An Illustrative Revision Handoff
Suppose the peer reviewer examines revision v2 and requests a routing correction. The designer issues v3. Before release, the reviewer verifies the corrected route and identifies any consequences for cable lengths, drawings, quantities and costs. The release record references v3 and the relevant closed finding.
If the crew still holds a downloaded v2 PDF, the fact that v3 exists in a cloud folder does not prevent outdated construction. Communicate the replacement, identify the applicable released set and manage access to superseded copies. This is a hypothetical workflow example, not a reported project or a legal document-control rule.
Field changes require another review of affected work and the applicable approval process. As-built drawings record accepted installed changes; they do not retrospectively approve them.
Improving the Process with Actual Evidence
Designers: document assumptions and use a written self-check before handoff. Keep equipment and source revisions consistent. Do not hide an unknown site value behind a convenient default.
Design managers: assign qualified reviewers, define authority to release work and use realistic response targets based on actual workload. Avoid requiring arbitrary numbers of comments; require evidence that the assigned scope was examined.
Installers: confirm the released revision before affected work, compare accessible site conditions with the design and report discrepancies through the change process. Photographs support records but do not automatically replace an inspection.
Measure review effort, queue time, repeat findings, unresolved critical issues and downstream corrections using defined project cohorts. Distinguish review time from customer or authority waiting time. Do not claim an 80% error reduction, universal tenfold cost multiplier or fixed payback period without actual supporting data.
Discuss your review workflow with SurgePV using a representative project. Confirm the demonstrated collaboration, revision and export functions and the human responsibilities they support.
Frequently Asked Questions
Is customer approval the same as technical approval?
No. Customer agreement concerns the stated project and commercial scope. Required technical, professional, permitting and utility decisions have separate responsibilities.
How long should design review take?
It depends on scope, complexity, source completeness and reviewer workload. Set measured internal targets without promising authority or customer turnaround times.
Do small projects need review?
Review critical assumptions, compatibility and required approvals regardless of size. Internal review can be proportionate to risk; professional and authority requirements depend on the actual project and jurisdiction.
Does cloud versioning prevent outdated drawings being built?
Not by itself. Identify the reviewed and released revision, communicate replacements and manage superseded exports and field copies.
Related Glossary Terms
About the Contributors
Solar-industry contributor
Nimesh Katariya contributes to SurgePV content concerning solar project workflows. This profile intentionally does not assert certifications, project totals, seminar counts, or technical-review authority without retained verification evidence.
Editorial contributor · SurgePV
Rainer Neumann is credited as an editorial contributor on SurgePV content. This profile does not assert engineering credentials, project totals, software-testing experience, education, speaking engagements, or media citations because independent verification evidence is not retained in the publication record.
