Solar Design Single Source of Truth: Rollout Plan

Last updated: November 2026

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 bill of materials (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 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.

SurgePV publishes this post and sells solar design software.

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?

A common interpretation is “put everything in one application.” That is neither necessary nor credible for most installers and EPCs. A customer relationship management system (CRM) may own the opportunity, while the solar platform owns the design and an enterprise resource planning system (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, single-line diagram (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 is a proposed responsibility map, not a product-feature matrix. SurgePV supports the design functions documented below. Verify the configured outputs and keep purchasing, accounting, construction and authority decisions with their designated owners.

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:

In an illustrative commercial and industrial (C&I) design example, imagine a 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?

Treat the module substitution as a proposed change until the responsible reviewers accept it. Ask the designer to identify every affected record and the buyer to preserve the supplier evidence. If a proposal has already been sent, the sales owner needs a clear instruction about whether to withdraw or replace it.

The communication channel can help people respond quickly, but the accepted decision still needs a durable record. Save the reason, supporting equipment documentation and release decision where the receiving team can find them without access to a private chat thread.

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’s documented scope includes 3D roof modeling, array layout, shading analysis, energy-yield modeling, financial modeling, electrical workflow support, bill-of-materials output and proposal generation. Assign authority only after checking whether the offered configuration supports the evidence and controls your team requires.

Use a representative project to inspect the input and output boundaries. Ask how the accepted geometry is identified, how equipment changes are reflected in subsequent work and how a receiving reviewer can trace a proposal to its design basis. These are evaluation questions, not claims that every control is native to the software.

For design modeling, review the source geometry and the resulting array. For energy and financial scenarios, review the equipment, loss and tariff assumptions. For proposal preparation, inspect how the output identifies scope and limitations. Confirm exact report formats and available exports during the demonstration.

Approval history, role permissions, comments, restoration and cross-system integration need explicit verification. If a required control is external, name the system and person responsible. A documented manual release can be appropriate when it is reproducible and receiving teams know which artifact they may use.

The project owner should maintain the dependency checklist. A geometry or equipment correction can require a new layout, energy result, electrical review, bill of materials and customer offer. Verify each affected output rather than assuming one edit automatically updates and approves every downstream record.

A design platform also does not replace the responsible engineer, utility or authority. Keep professional approval and formal transmittal evidence in the designated process. Reference accepted changes in the current working model so later proposals do not silently return to an earlier assumption.

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.

An electronic document management system (EDMS) may govern formal document registers, transmittals and response cycles. Define those requirements with the engineer and document controller before assigning them to a general project workspace.

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, customer results or SurgePV pricing. All monetary figures are USD.

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.

Ask for the offered configuration and product limits in writing. Record any required integration, history or approval function as unresolved until its behaviour has been demonstrated and its scope agreed.

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 supports roof modeling, array layout, shading, energy-yield and financial modeling, electrical workflow support, bill-of-materials output and proposal generation. Evaluate how those functions fit the ownership matrix and retain appropriate professional review.

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 solar design single source of truth identifies the authoritative record for each important field and deliverable. It names the owner, release status and version that downstream teams may use.

Does a single source of truth require replacing every tool?

No, separate tools can remain authoritative for different records. Define field ownership and reconcile controlled handoffs between design, engineering, procurement and business systems.

Why is WhatsApp not enough for solar project handoffs?

A chat thread should not be the only copy of an accepted design decision. Record the value, evidence and release in the designated project system, then link messages to it.

Which system should own the BOM and SLD?

Assign design-derived quantities and electrical inputs to the designated design record, with formal issues controlled by engineering. Procurement should own supplier, purchase-order and receipt records and return substitutions for technical review.

How do we manage approved versus working designs?

Use explicit statuses and a named release authority for each intended use. Mark replaced outputs as superseded and identify their successors before issuing revised instructions.

Can SurgePV replace CRM or construction project software?

SurgePV supports documented solar design, modeling, bill-of-materials and proposal functions. Evaluate required controls in the offered configuration and retain separate ownership for accounting, purchasing, construction and formal approvals.

What should we measure during a source-of-truth pilot?

Measure search time, duplicate entry, revision work, release delays and unresolved exceptions. Ask a qualified new reviewer to reconstruct the accepted design and handoffs without relying on the original author.