Developer Notices
View and acknowledge deficiency notices sent to your organization by utilities.
A project's partial document report is not a utility deficiency notice or an approval. It can show applicant self-check findings before any utility screening; notice authority and the response workflow below remain separate.
Salesforce connector boundary
The default-disabled Salesforce connector returns utility-internal decision support; it does not send applicant notices or change the Salesforce regulatory queue status. Automatic package freezing also makes no notice or queue/status changes. Source-managed revisions stop for staff review once adjudication or notice work begins. This does not change the developer response workflow for ordinary submitted applications.
What Are Deficiency Notices?
When a utility reviews your interconnection application and identifies issues, they send a deficiency notice listing the findings that need to be resolved. Each notice includes the specific deficiencies, their severity, and a deadline for your response.
Deficiency notices are part of the standard interconnection review process. Receiving a notice does not mean your application is rejected — it means the utility needs corrections or additional documentation before they can proceed.
If a document has been replaced, GridWonk excludes findings tied to the older bytes. The utility must finish reviewing the current document versions before it can draft the next packet-wide notice, so a notice cannot silently omit a document that is waiting for re-review.
Where to Find Notices
Notices appear on your Dashboard in the Deficiency Notices card. This card is visible to all members of developer organizations.
The card header shows a count of notices awaiting your acknowledgment.
Notice Table
Each notice displays the following columns:
| Column | Description |
|---|---|
| Application | The project name and official utility application number, when one has been assigned |
| Notice | The notice subject line, round number, and count of outstanding deficiency items |
| Status | Whether the notice is awaiting acknowledgment or already acknowledged |
| Due | The response deadline set by the utility, or "Not set" if no deadline was provided |
| Action | An Acknowledge button for pending notices, or "Completed" for acknowledged ones |
Acknowledging a Notice
When you receive a notice with status Awaiting Acknowledgment, click the Acknowledge button to confirm you have received and reviewed the notice.
Viewing and acknowledging are separate permissions. Viewers and read-only grant users can review notices but cannot acknowledge them. Acknowledgment requires an active Member, Admin, or Owner role; grant-derived access also requires a write or admin grant within the submission scope.
Acknowledging a notice:
The action rechecks current membership and the exact scoped grant under the application lock. Acknowledging an already acknowledged notice succeeds without writing another history entry. Pending or held delivery is not a sent notice; application changes wait for its resolution.
Verified email-provider receipts, when separately activated, are delivery evidence only. They cannot acknowledge a notice for you or confirm that you read it. The dependent utility-event layer records an actual acknowledgment once; its subscriptions belong to the receiving utility, not automatically to the applicant or a consultant with project access.
- Records a timestamp of your acknowledgment
- Updates the notice status to Acknowledged for both you and the utility
- Signals to the utility that you are aware of the findings
Acknowledgment does not mean you agree with the findings or have resolved them — it confirms receipt.
Notice Statuses
From the developer perspective, notices have two statuses:
| Status | Meaning |
|---|---|
| Awaiting Acknowledgment | The utility has sent the notice and it requires your acknowledgment |
| Acknowledged | You have acknowledged receipt of the notice |
Starting Your Response
When a notice has been sent for one of your projects, the project Overview and Review views show a Start response action. This control is developer-client scoped: utility and GridWonk reviewer organizations do not receive it, and a consultant's own home organization does not receive it. A consultant may see it after switching into a granted developer-client context, but the server succeeds only when that context still has write-capable, in-scope access. Selecting it moves the project into Resubmission Under Development, records the stage change in application history, and unlocks the working document set for correction.
Start response is idempotent: if a teammate already started the response, the action simply reports that and writes nothing — no duplicate history entry is created. Attaching the first corrected document to the project performs the same stage transition automatically, so the response stage is recorded even when nobody presses the button first.
After Acknowledgment
Once you acknowledge a notice, review the deficiency items and prepare your response. Common next steps include:
- Correcting the identified issues in your application documents
- Gathering additional documentation requested by the utility
- Uploading corrected documents through the platform. A document that is linked to a project — a link row, logical version, or submitted package — still rejects different-byte replacement, so follow the Upload safety states and use a new filename when instructed. Only unlinked documents accept replacement bytes. Documents frozen in a submitted package cannot be changed or removed.
- If one accepted PDF contains multiple document types, use More actions → Split PDF while the project is editable. Assigned or previously reviewed 2–250-page PDFs are eligible too. Confirm page ranges and types; the children need fresh review. The original and earlier findings remain historical after success. A pending or failed split pauses new review and submission until it succeeds or you choose Keep original; Retry split safely retries a failed attempt.
- Contacting the utility's interconnection team if you have questions about specific findings
Acknowledgment does not resubmit your application. It only records receipt. When you are ready to respond, use Start response (or attach the first corrected document) to open the resubmission working set, then link the corrected documents requested by the utility and follow the utility's instructions for the next screening round.
Finish or cancel any unfinished upload batch before resubmitting. The server refuses to freeze the new package while an unexpired batch remains open, processing, or awaiting CAD pairing; that refusal does not change your documents, submission stage, or earlier packages. Resubmission is not blocked by the utility's submission acceptance: your correction goes to the utility that already accepted your original package, even if that utility has since stopped accepting new submissions or has no qualified reviewer at that moment. In that last case no reviewer receives an in-app notice, but the resubmitted package is still delivered and stored. See Private Reviews and Utility Submissions.
The corrected immutable package returns to the utility queue as Pending. The utility starts its whole-packet review with Screen Selected or an authorized integration. The review moves the application to Screening before work starts and Screened when complete. A failed start or run restores its earlier status once no other utility review is active. Resubmitting does not start another legacy document-processing pass. Earlier packages and notice rounds remain in history, and completed automated screening is not utility approval.
If the utility re-screens your resubmitted application and finds remaining issues, they may send a follow-up notice (Round 2, Round 3, etc.). Each round links back to the previous notice so you can track the full history.
Cross-Organization Visibility
As a developer, you see notices for all applications submitted by your organization, regardless of which utility sent them. If your organization has applications with multiple utilities, all notices appear in the same Deficiency Notices card.
This works because the notice is linked to a shared submission record:
- the utility still owns the review workflow
- your developer org is linked as the applicant on that same submission
- you can see the notice history without becoming the owner of the utility queue row
Related
- Notices — How utilities create, review, and send deficiency notices
- Results — Understanding validation results and deficiency details
- Organizations — Managing your organization and roles