Solar Design Source of Truth: Workflow Guide

A sales manager approves a module change in chat. The designer updates the layout, but the estimator still has the old yield. Procurement opens an earlier BOM, and the customer receives a proposal that shows the first module count.

The problem is not the chat application. The problem is that the team never declared which record owns the current design decision, who can release it, or how every affected output becomes current.

A solar design workflow single source of truth solves that governance problem. It does not mean one application must run the entire EPC. It means one authoritative system owns each important field, one role approves its release, and every message or external handoff points back to that record.

In this guide:

• What a single source of truth means for solar design
• Why it does not require one app for the whole company
• How chat, email, spreadsheets, CAD, and PDFs lose revision context
• Which system should own each solar project field
• What SurgePV can own from design through proposal
• What remains in CRM, engineering, procurement, construction, and utility systems
• How to implement status, approval, and release controls
• How to calculate the business case with your own project data

What Is a Solar Design Single Source of Truth?

A solar design single source of truth is the declared authoritative record for each field and deliverable from site model through customer proposal. It answers 4 questions without relying on memory: Which system owns the current value? Who can change or approve it?

What is its status? Which released version may downstream teams use?

The phrase is often misunderstood as “put everything in one application.” That is neither necessary nor credible for most installers and EPCs. A CRM may own the opportunity, while the solar platform owns the design and an ERP owns the purchase order.

The source-of-truth model works at field level. Roof geometry can be authoritative in the solar model.

The utility bill may remain an attached evidence file with a named reviewer. Supplier price and receipt status can remain authoritative in procurement or ERP.

Three record types need separate treatment:

General document-governance guidance supports this separation. Microsoft’s SharePoint version-history overview describes viewing and restoring earlier versions, identifying who changed an item, and supporting auditability. Those principles are useful here even though a solar design platform is not a complete document-management system.

Version history alone is not enough. Ten saved versions still create uncertainty if nobody knows which one is approved for a proposal or purchase. The team needs statuses, release authority, and a visible link between the current design and its outputs.

For solar work, the connected record should cover the decisions that move together. A roof or site change can affect module placement and shade. An equipment change can affect strings, BOM, SLD, production, financial results, and the customer offer.

The benefit of solar design platform is therefore not “everything is online.” The benefit is that related design-to-proposal decisions can share a controlled project context, while specialist business systems keep their rightful scope.

One Source Does Not Mean One App for the Entire EPC

One source of truth means one authority per field, not one vendor for every workflow. An EPC can use several platforms and still have excellent control. Confusion begins when 2 systems both appear authoritative for the same value or when no system owns it at all.

This article differs from our guide to consolidating solar software tools. Stack consolidation asks whether the company can reduce vendors, licences, and repeated work. Source-of-truth governance asks who owns a field and a release even when the tools remain.

Use this boundary map as a starting point:

This boundary prevents product overreach. SurgePV can connect roof or site modeling, module layout, shade and production analysis, string and inverter configuration, BOM, SLD, financial analysis, and proposal output. It does not become the system for dispatch, inventory, purchase orders, site diaries, accounting, formal transmittals, or utility processing.

Several systems can exchange a project identifier without a claimed native integration. A designer can export an approved BOM and place its revision in the procurement record. An external engineer can return a stamped artifact that the team references against the accepted design.

Document the handoff even when it is manual. Define the sender, recipient, approved input, issued artifact, required metadata, and reconciliation step. A controlled CSV or PDF handoff can be safer than an undocumented integration that nobody owns.

The right target is not “zero tools.” It is zero ambiguity about which system owns the value used for the next decision. A company can then consolidate parts of the stack later without first moving unclear data into a new home.

How Messaging and File Handoffs Break Solar Projects

Messaging is good for alerts, discussion, escalation, and short-lived context. A designer can ask sales for a utility bill.

Engineering can flag an equipment conflict. Procurement can warn that a selected module is unavailable.

The weakness appears when the thread is the only place where the decision exists. Attachments can travel without revision context. The current answer may sit deep in a conversation, and a new teammate may not know which search term the original participant used.

Compare the jobs directly:

Imagine a C&I project where sales approves a different module in a group chat. Design changes the layout from 240 modules to 228 because the dimensions differ. The string plan, BOM, SLD, yield, and proposal all need review.

If the message is treated as the record, each person must interpret what “approved” means. Did the customer approve the visual change?

Did engineering approve electrical compatibility? Did procurement confirm the exact regional part number?

Solar practitioners describe similar fragmentation as individual experience. One solar software discussion describes site data moving into a design tool before a finalized BOM is entered again in an estimating system. Another EPC systems discussion separates CRM, field execution, scheduling, visits, and progress tracking while warning about careless mid-project migration.

Those comments are anecdotal, not proof of frequency. They still illustrate why a single source of truth starts with scope. The company needs a rule for each decision, not a generic instruction to “keep the project updated.”

Competitor publishing also confirms commercial interest in the problem. A PVcase article on solar project version control discusses file desynchronization and controlled project data. Treat that page as vendor positioning, not neutral evidence, but note the buyer intent: teams are looking for a way to stop project versions from diverging.

Use this message rule: chat may contain the notification, question, or link, but never the only copy of the accepted change. The designated system receives the value, evidence, author, reason, status, and release action.

Build a Solar Project Field-Ownership Matrix

The field-ownership matrix turns a slogan into an operating model. List every value that can change a design, cost, approval, or customer output. Then assign a system owner, role owner, evidence requirement, and release artifact.

Start with the design-to-proposal lifecycle:

Do not copy this table without adapting it. A residential installer may combine designer and estimator roles. A large EPC may split simulation, electrical design, procurement engineering, and commercial approval across departments.

Every row needs one system owner. Multiple people can contribute evidence, but the approved value should not be editable independently in 2 places. When a downstream system must copy it, label the copy and define reconciliation.

Every row also needs a role owner. Naming “engineering” is often too broad. Use a job role such as lead electrical designer, proposal approver, procurement lead, or project manager.

Add an evidence rule. Geometry may be based on imagery for feasibility but require a field check before construction release. A tariff may need a utility source and effective date, while a CAPEX value may require an estimator’s approved cost basis.

Finally, define the released artifact. A working model is not a released layout.

A generated BOM is not approved for purchase. A proposal draft is not the offer the customer signed.

When 2 systems disagree, do not ask the loudest person to choose. Use the matrix. The owner of the authoritative field reviews the evidence, records the accepted value, and triggers downstream reconciliation.

What SurgePV Can Own From Design Through Proposal

SurgePV can serve as the connected design-to-proposal record for the fields its current product covers. That begins with the roof or site model and continues through module placement, shade and yield analysis, electrical configuration, design-derived outputs, financial analysis, and proposal generation.

The solar designing workspace covers 3D rooftop modeling, automatic and manual module placement, string sizing, inverter configuration, BOM, and SLD generation. Solar shadow analysis software connects obstruction shading and irradiance work to the project model.

The energy and financial modeling tool can hold energy yield and proposal-stage financial scenarios such as payback, IRR, and NPV. Solar proposal software then creates the branded customer output from the project’s visuals and financials.

Current site documentation also references team access, commenting, design review, shared projects, version history, and role-based access. Those controls can support a common design record when the company pairs them with its own status and release procedure.

Do not interpret that statement as formal EDMS equivalence. A solar workspace and an enterprise document-control system solve different problems. The buyer should test the exact history, role, comment, and approval behavior needed by its team.

Clara is an AI assistant for design and proposal copy. It can support work inside the documented product scope, but it is not an autonomous project manager. Do not assign it construction scheduling, procurement decisions, engineering approval, or cross-system reconciliation that still belongs to named roles.

The core value is change propagation. When a project owner corrects roof geometry or changes equipment, the team can review layout, strings, BOM, SLD, production, financials, and proposal from one project context. Each output still needs the appropriate release gate.

For solar installers, that connection can reduce questions about which technical result supports the current offer. For a C&I EPC, it can give design, engineering, estimating, and sales a shared point of reference before the project crosses into formal engineering, procurement, and construction systems.

What Must Stay in CRM, EDMS, Procurement, and Field Systems

A credible source-of-truth plan is explicit about what the solar design platform does not own. Pushing every record into the design system would reproduce the same ambiguity under one login.

Keep these domains in their specialist systems:

• CRM: lead source, contact history, consent, pipeline stage, sales activity, and account ownership.
• ERP and accounting: vendor master, invoice, payment, tax, budget control, and general ledger.
• Procurement: supplier quote, price, pack quantity, approved substitute, purchase order, delivery, receipt, and stock.
• Construction scheduling: crew assignment, dependency, calendar, site readiness, daily progress, and completion status.
• Field service: work order, dispatch, mobile capture, punch item, maintenance visit, and warranty case.
• Formal EDMS: master document register, transmittal, RFI or submittal cycle, response code, vendor register, and formal issue status.
• Engineering authority: calculations, professional review, digital signature, stamp, and issued-for-construction approval.
• Utility and AHJ portals: application, fee, correction, inspection, permission, and official acceptance state.

A current power and EPC document-management discussion asks about master document lists, transmittals, response cycles, vendor registers, and versioned model files. That practitioner request is anecdotal, but it shows why “stores project files” is not the same as “replaces an EDMS.”

The handoff between systems should carry 6 items: project ID, source system, source revision, release status, issued date, and accountable role. Include a short reason when the handoff follows a meaningful change.

For example, procurement receives Project 1842 / Engineering BOM Rev C / Approved for purchase / released by design lead. It then owns supplier and purchase-order activity. If procurement proposes a substitute, the change returns to the design authority before the buyer releases an order.

An external engineer may receive an approved design basis and return signed drawings. The formal engineering process owns that issued artifact. Accepted engineer changes must then be reconciled into the current solar model so later proposals or equipment lists do not use the earlier assumption.

No native integration should be assumed unless the current product documentation confirms it. A defined manual handoff with ownership, metadata, and reconciliation is an acceptable starting point.

Status, Approval, and Release Governance

A single source of truth needs more than one current file. It needs a small set of statuses that every participant interprets the same way. Use enough states to protect releases without creating a bureaucracy nobody follows.

Microsoft’s document versioning and approval guidance discusses major and minor versions, content approval, check-in and check-out, metadata, and change comments. Its co-authoring overview describes centralized access to current versions and the ability to track earlier versions.

Those sources establish general governance patterns. They do not prove that SurgePV implements every SharePoint control. During evaluation, test the actual status, history, permission, and collaboration behavior in the solar platform.

Assign responsibility for each state transition:

Meaningful changes need a short reason and evidence. “Changed module” is incomplete. “Module A unavailable; Module B accepted after fit, string, yield, BOM, SLD, cost, and proposal review” gives the next reviewer a reconstruction path.

Use a release gate before any downstream handoff. The gate confirms the project ID, source revision, intended use, approver, date, and generated artifacts. A BOM for engineering review should never look identical to a BOM approved for purchase.

Apply the message rule consistently. A chat post can say that Rev C is released and include the link. The chat message should not be the only location of approval or the only copy of Rev C.

Finally, create a reconciliation rule. If a stamped sheet, supplier response, field finding, or utility correction changes a design-owned value, the field owner must update the current model or document why it remains different. Unreconciled exceptions belong on a visible queue with a named owner.

Follow One Revision Through the Whole Workflow

Use a module substitution to test the source-of-truth model. A project has an approved preliminary proposal based on Module A. Procurement reports that Module A is unavailable and suggests Module B.

The message is an alert, not the technical approval. The design owner first records the proposed substitute and evidence. Engineering then reviews dimensions, electrical characteristics, the applicable equipment configuration, and project requirements.

If Module B is accepted, update the selected equipment in the solar design record. Then review every dependent output:

The automated solar BOM workflow explains the material-release controls in detail. The automated solar SLD workflow covers the related electrical-document handoff.

Older outputs become superseded, not deleted without trace. A teammate should be able to see that Proposal Rev A described Module A and that Rev B replaced it after technical and commercial review.

This example exposes the difference between connected work and automatic approval. Software can recalculate or generate an output. Named roles still decide whether the evidence, electrical design, financial result, and customer communication are acceptable.

It also preserves system boundaries. The design platform owns the accepted configuration and design-derived outputs. Procurement owns the purchase order, while the engineering control process owns signed or formally issued sheets.

Implement a Solar Design Source of Truth in 9 Steps

Do not begin by migrating every active project. Start with one failure, create the ownership model, and test exceptions before expanding. A poorly defined migration can move ambiguity into a newer interface.

1. Reconstruct One Recent Revision Failure

Choose a project where a wrong version, missing approval, or unclear status caused investigation or rework. Draw every touchpoint from customer input to design, engineering, procurement, and proposal.

Record facts rather than blame. Which value changed? Where was it approved?

Which files stayed old? Who discovered the conflict?

2. Inventory Decision-Grade Fields

List the inputs and outputs that can change layout, equipment, energy, cost, approval, or customer communication. Include utility data, geometry, obstructions, equipment, strings, losses, yield, BOM, SLD, CAPEX, tariff, proposal, and formal engineering artifacts.

Do not list every database field. Focus on values whose ownership must be clear for the next project decision.

3. Assign One System and Role Owner

Complete the ownership matrix for each field. If 2 systems currently appear authoritative, select one and label the other as evidence, cache, export, or downstream record.

Assign a job role that can resolve a conflict. A system without a responsible person is only a storage location.

4. Archive Duplicate Authorities Read-Only

Do not erase historical records. Mark older spreadsheets, local CAD files, and proposal PDFs as superseded or read-only where practical. Point each retained copy to the current project and revision.

Avoid changing all active projects in the middle of construction unless a controlled plan justifies it. New projects or defined stage boundaries are safer pilot points.

5. Define Status and Release Rules

Write the meaning of working, review, approved or released, superseded, and rejected. State who can move a record between statuses and which status each downstream team may use.

Add a message rule and a change-reason rule. Keep them short enough to follow under deadline pressure.

6. Document External Handoffs

Map the interface to CRM, external engineering, EDMS, procurement, construction, accounting, and utility systems. Define the approved input, issued output, metadata, recipient, and reconciliation action.

Do not invent integration support. A controlled export and receipt procedure can work while the company evaluates automation separately.

7. Pilot 3 Project Types

Choose one routine job, one revision-heavy job, and one exception project. The routine project tests usability. The revision-heavy project tests change propagation.

The exception project tests system boundaries. Use a supplier substitution, field-discovered obstruction, external engineering change, or utility correction that must leave and re-enter the design workflow.

8. Run the New-Teammate Audit

Ask a qualified teammate who did not build the project to reconstruct it. They should identify the current design, source evidence, meaningful changes, approvers, released proposal, external handoffs, and unresolved exceptions.

Do not coach them through the folder structure. Every question they must ask the original designer reveals a missing field, label, link, or ownership rule.

9. Measure, Correct, and Expand

Track search time, duplicate entry, status chasing, revision touches, wrong-version investigations, release cycle time, and unresolved exceptions. Compare pilot projects with a sample of the old workflow.

If the exception route fails, fix it before expansion. A process that works only for unchanged residential designs is not ready for mixed project work.

Measure Coordination Cost and ROI

Build the business case from observed project work. Do not use a generic claim that centralization saves a fixed percentage. Sample recent projects and time the coordination work your team actually performs.

Use these formulas:

monthly coordination cost = projects × (search time + re-entry time + status-chasing time + revision-reconciliation time) × loaded rate

monthly rework exposure = wrong-version incidents × average investigation, redesign, and reissue cost

future monthly cost = platform and administration cost + remaining handoff time + exception reconciliation + residual rework

net modeled value = current coordination cost + current rework exposure − future monthly cost

The following example is hypothetical. Its inputs are not industry averages.

Current coordination time is 28 × 1.75 = 49 hours. At the hypothetical loaded rate, monthly coordination cost is $3,038. Current rework exposure adds $630, producing a combined modeled cost of $3,668.

Assume the pilot leaves 0.55 coordination hours per project, adds $850 in platform and administration cost, requires $240 for exception reconciliation, and retains $210 in residual wrong-version exposure. Future monthly cost is 28 × 0.55 × $62 + $850 + $240 + $210 = $2,254.80.

The modeled difference is $1,413.20 per month. That number is meaningful only if the inputs reflect observed work and the future process achieves its assumptions.

Separate 3 types of value. Avoided cost is spend that actually disappears, such as reduced overtime or outsourcing. Recovered capacity is time reassigned to other work.

Risk exposure is the estimated cost of events that may not occur every month. Report it separately so an infrequent expensive error does not become a guaranteed saving in the purchase case.

The pilot should also measure release quality. Fewer searches are useful, but the stronger outcome is that the team can identify the current design and released artifacts without asking the original author.

Test the Source-of-Truth Workflow in a Demo

Use a revision-heavy project during the product demo. A clean vendor sample shows the first design. Your own project shows whether the workflow survives change.

Complete the initial model, shade and production analysis, electrical configuration, BOM, SLD, financial case, and proposal. Then change the module or a decision-grade roof dimension.

Score the session against this checklist:

After the revision, run the new-teammate test. Give a qualified colleague the project without a verbal briefing. Ask them to identify the accepted equipment, current yield, released proposal, latest BOM and SLD, change reason, approvers, and external actions.

Ask the vendor what happens when systems disagree. A useful answer describes ownership and reconciliation. A warning sign is a claim that putting files in one workspace automatically makes every value current.

Also ask for product limits in writing. Confirm that Clara AI assists within documented design and proposal work rather than acting as CRM, scheduler, procurement manager, engineer, or utility coordinator.

The best demo outcome is a realistic ownership map. You should leave knowing what becomes authoritative in SurgePV, what remains external, and what the team must do at each release boundary.

Conclusion: Make Authority Visible

A solar design source of truth is a governance decision before it is a software decision. It declares which system owns each important value, which role can release it, and how a downstream team identifies the current artifact.

SurgePV can connect the design-to-proposal record across roof or site modeling, module placement, shade and production analysis, strings and inverters, BOM, SLD, financial scenarios, and branded proposals. That scope is valuable precisely because it has a boundary.

CRM, ERP, procurement execution, formal EDMS and transmittals, engineering approval, construction scheduling, field service, accounting, and utility portals remain external. Documented handoffs connect those authorities without pretending they are one system.

Take 3 actions next:

1. Reconstruct one recent failure. Find the value that changed, every file it touched, and the point where versions diverged.
2. Publish the ownership matrix. Name one system, role, status set, release gate, and reconciliation path for each decision-grade field.
3. Test one live revision. Change equipment or geometry after the first proposal and inspect every design output and external handoff.

Review the pilot with someone who did not create the project. If that person can explain the current design, evidence, approvals, releases, and exceptions, the process is becoming reconstructable.

Publish the boundary beside the ownership matrix. A team member should know where to update a sales stage, where to correct a layout, where to release a purchase order, and where to find a stamped drawing. This solar software governance rule prevents a shared workspace from becoming another unclassified file store.

Schedule a short audit after the first month. Look for private spreadsheets, forwarded attachments, and unrecorded approvals that returned under deadline pressure. Treat each workaround as evidence of a missing field, owner, status, or handoff, then correct the operating procedure before scaling it.

If you want to map that process against the product, book a personalized SurgePV demo. Bring a revision-heavy project, its current messages and files, and the question your team struggles to answer today: “Which version can we use?”

Frequently Asked Questions

What is a single source of truth in solar design?

A single source of truth is the declared authoritative record for each solar design-to-proposal field and deliverable. It identifies the owning system, editing or approval role, current status, evidence, and released revision.

It does not require every company record to live in the same application. It requires each important value to have one authority and a controlled handoff when another system needs it.

Does a single source of truth require replacing every tool?

No. A company may keep a CRM for opportunities, a solar platform for design, an EDMS for formal documents, an ERP for accounting, procurement tools for purchase orders, field software for construction, and official portals for utility work.

Create a field-ownership matrix across those systems. Where data crosses a boundary, carry the project ID, revision, status, date, responsible role, and reconciliation rule.

Why is WhatsApp not enough for solar project handoffs?

WhatsApp and other messaging tools are useful for rapid alerts and discussion. A thread is weak as the only project record because a decision can lose its field context, revision status, evidence, or release authority when it is forwarded or buried.

Use chat to notify people and link to the controlled record. Store the accepted change, author, reason, evidence, status, and released output in the designated system.

Which system should own the BOM and SLD?

The solar design record should own current design-derived quantities, equipment configuration, BOM, and SLD outputs. That keeps them aligned with the accepted layout and electrical design.

Procurement should own supplier, price, pack, stock, purchase order, delivery, and receipt data. A formal engineering or EDMS process should own stamped or issued sheets, transmittals, response cycles, and professional approval.

How do we manage approved versus working designs?

Use explicit statuses: working, review, approved or released, superseded, and rejected. Define which role can move the project or artifact between states and the intended use of each release.

Record a reason and evidence for meaningful changes. Mark older releases as superseded and point to the replacement, rather than leaving several similar files for the next person to interpret.

Can SurgePV replace our CRM or construction project software?

No. SurgePV can connect the solar design-to-proposal record, including 3D modeling, layout, shade and yield, strings and inverters, BOM, SLD, financial analysis, and proposal generation.

It does not replace CRM, accounting or ERP, procurement execution, construction scheduling, field service, formal EDMS or transmittal control, engineering approval, or utility portals. Those systems keep authority for their domains.

How should external engineers and subcontractors fit the workflow?

Define the artifact they receive, the source revision and status required before issue, the expected return deliverable, and the system that owns formal approval. Include project ID, issued date, sender, recipient, and accountable role.

When an external response changes a design-owned value, reconcile the accepted change into the current solar model. Keep the returned issued artifact in its formal document-control process or reference it from the project record.

What should we measure during a pilot?

Measure time spent searching, re-entering data, chasing status, reconciling revisions, and investigating wrong versions. Track release cycle time, the number of touches after a change, unresolved exceptions, and any reissue cost.

Run a reconstruction test with a new teammate. They should find the current design, evidence, approvers, released proposal, BOM, SLD, external handoffs, and open exceptions without asking the original designer.