Applications

Trial and prepaid screeningCopy Anchor Link

An eligible utility review uses the utility workspace's processing allowance and the exact submitted package. The applicant's private review remains separate. A saved usable packet report consumes one review credit; reading existing authorized reports does not. Completed screening is decision support and does not automatically approve the application or send a notice.

The public plugin can perform eligible intake and review operations and read the resulting application history within its confirmed workspace. Package submission, adjudication, and notice writes remain website workflows. Switching the website's active workspace does not retarget the plugin connection.

Applicant self-check findings and partial reports remain distinct from utility screening and approval. This change does not grant applicants utility review authority or alter package-pinned utility review.

After an applicant-confirmed PDF split completes, current findings and packet counts use the resulting documents, not the retained original. Earlier findings remain available in history. New review starts and submission pause while a confirmed split is pending or failed; the applicant can inspect progress, retry, or keep the original from More actions → Split PDF.

Salesforce packet pilotCopy Anchor Link

Salesforce-sourced reviews are implemented but disabled pending acceptance. A source application keeps one application identity through captured revisions. Queue filtering checks the linked reviewer's current Salesforce access before pagination and counts. More than 200 source candidates require narrower filters. Automatic human- and service-owned package creation is implemented; the real utility sandbox pilot remains unverified.

If Salesforce permission checks are temporarily unavailable, ordinary applications and successfully authorized Salesforce applications remain usable. The list warning and partial count labels explain that unverified Salesforce applications are hidden and excluded from totals. Use Refresh to retry live permission checks. An empty partial list does not mean there are no applications. Application-list database query failures still report an error.

Application Queue OverviewCopy Anchor Link

Pending, held or provider-accepted-but-unfinalized notice delivery blocks conflicting review, package and response-stage changes. Check the request in Notices and resolve its status before retrying the application change. Provider acceptance alone is not inbox delivery.

An exact retry of an active screening job reuses it without another review-budget charge, even when the reviewing utility has reached its review cap. Request-rate limits still apply. Manual freeze remains limited to the utility's own draft. A study requirement saved after screening applies to the next submission, leaving the frozen package and its report unchanged.

Saving the same normalized study requirement again preserves its existing version. The dependent utility-event release records actual package and decision changes for receiving-utility webhook subscriptions; retries do not create another change. These integration events do not alter queue counts, screening authority, or the distinction between an automated review and a human decision. Schema activation and production release remain separate approval gates.

The Applications tab is your central view for managing incoming interconnection applications. It shows all submissions for your utility organization with filtering, sorting, and batch operations.

The server resolves your organization's feature settings before it selects the queue layout and workflow-status data. A setting for one organization cannot expose or change another organization's applications.

Archived synthetic demo submissions remain available as audit history but do not appear as active queue work.

An approved synthetic developer may test several utilities. Each utility's queue remains scoped to its own organization; adding another destination does not combine utility reviewer queues.

Test-account status comes from protected organization settings, not an organization name or a browser-supplied label. Synthetic packet routing requires the developer and utility organizations to name each other and agree on the real utility whose requirements apply. An invalid pairing is rejected instead of sending the test project to a real utility's queue. A test label never grants review or cancellation authority.

Utility-side applications still use the utility application number as the formal queue identifier. Developer console projects use a project name first, and GridWonk keeps any temporary internal reference hidden until an official utility application number exists. The customer API, SDK, CLI, and MCP surfaces reuse that same generated-reference rule, so creating or reading a draft outside the console does not produce a second project identity.

Workspace v2Copy Anchor Link

Every utility organization sees the queue as the Applications rail destination. Opening a row selects the application (?view=applications&app=…): its views — Overview, Documents, Review, Communications, History — move into the header, and the back control returns to the queue. An application the utility originated itself opens on the draft workspace (the same Documents and Review views developers use) until Freeze package turns its documents into the immutable package the reviewer flows below work from. Cmd+K opens the destination palette. Old six-tab bookmarks redirect to the matching destination. The Applications V2 feature still controls package reads and both upload entry points; disabling it does not restore the removed shell or base64 uploader.

Utility-owned packets and developer detailsCopy Anchor Link

A packet created by your utility stays owned by your utility and private to its authorized staff by default. Entering a developer's name or contact information records who the project concerns; it does not create an account, invite anyone, transfer ownership, or give that developer access. An unknown developer does not prevent intake or internal review. Developer invitations are not part of this release.

For your own editable packet, open Overview → Human confirmations to complete any required placard, native CAD delivery, or study-documentation confirmation. You must be a direct, active member of the utility with write access; a viewer role, a grant from another organization, or an impersonated session cannot supply that authority. Confirm facts yourself, including placard placement, materials, mounting, and contacts—not just what a drawing appears to show. The saved record is labeled Confirmed by utility staff and retains the staff member, organization, time, and exact document versions. It does not sign a customer's declaration. Replacing a linked document requires a new confirmation. See Human confirmations.

These controls do not let utility staff change confirmations on an applicant-owned packet. Your own packet's review remains utility screening, with the utility as payer; recording a developer does not turn it into an applicant self-check. Existing budgets and readiness requirements still apply.

The utility-owned confirmation and review repair requires the reviewed database migration and matching application deployment. Until both are active, a blocked review is not a passed review; do not create a dummy developer or change ownership to work around it.

Two Status FamiliesCopy Anchor Link

GridWonk tracks two related but different kinds of status:

1. Submission stage — where the applicant is in the formal submit/resubmit lifecycle
2. Review workflow status — where the utility is in screening and notice handling

Submission stageCopy Anchor Link

Review workflow statusCopy Anchor Link

Each utility-side review row also progresses through a review workflow:

The key idea is that a submission can remain the same project while moving through multiple review states and notice rounds.

Applications the utility originated itself (batch intake or a utility-created project) are owned by the utility organization (ADR-093). While their documents are still arriving they show the display state Intake in progress with the utility as the responsible party. That state comes from the shared workflow-status service, not from a new screening_status value; developer-submitted applications keep every state above.

Each formal submit or resubmit creates an immutable package snapshot of the document versions sent in that round. Submit and resubmit both re-check the current actor, active organization, grant scope, linked documents, and project stage inside the locked packet mutation before committing the package. The applicant can continue changing the live project working set only in an allowed draft or resubmission-development stage; earlier packages remain frozen for review history.

A developer's first project and packet review are private to the developer organization. The private review path is the default and remains available when Submit is enabled. Explicit Submit shares the frozen documents and the package-pinned packet report, not other private review history. The utility receives the application only after formal Submit, which checks that both GridWonk and the utility have accepted submissions for that state and program and that an active utility reviewer is available. A utility that has not completed this acceptance cannot receive a formal packet; the developer can continue preparing and reviewing the private project. A successful submission gives the utility's eligible reviewers an application link in their session inbox. An authorized utility owner or admin can manage acceptance under Settings → Integrations → Application packet submissions. GridWonk approves the same state and program separately; either party can stop future submissions without changing packages already received.

Acceptance gates only the first formal Submit. A resubmission after a deficiency notice goes to the utility that already accepted the original package, so it is not blocked if that utility later stops accepting new submissions. If no qualified reviewer is available at that moment, the resubmission is still delivered and stored, but no reviewer receives an in-app notice. See Private Reviews and Utility Submissions.

When a packaged site-plan version has a native DWG companion, the snapshot also pins that exact companion asset and its SHA-256 file fingerprint. Replacing the DWG later creates a new live logical version and does not rewrite the package the utility already received.

Authorized utility readers see the safe attachment name, size, and drawing-version label on the submitted package. From Documents, they can open the site plan and switch between its sanitized PDF and authorized native-drawing derivative. From Review, an exact CAD finding opens that same package-bound drawing at the matching entity; an identity mismatch is refused instead of showing a stale location. Utility readers cannot upload or replace the applicant's DWG, and the browser never receives the private native file bytes through these views.

Developer response stageCopy Anchor Link

Applicant submit and resubmit refuse an unfinished, unexpired upload batch before freezing a package. Finish or cancel that batch first; already accepted documents and earlier packages remain.

After a deficiency notice is sent, a developer organization can select Start response from project Overview or Review. The action moves the live project into Resubmission Under Development and records the transition in application history. Utility and GridWonk reviewer organizations do not receive that developer-only control; they continue to track the shared stage and later resubmission from the queue. Repeating the action after a teammate already started the response is safe and does not create a duplicate history row.

Review history remains available, but the active Screening view and notice workflow use findings for the current document generations only. When a linked document is replaced, earlier findings are hidden until the replacement is reviewed.

Consultants working from their own consultant organization do not receive developer-only lifecycle controls. When a consultant switches into a granted developer-client context, submit, start response, and resubmit still re-check the consultant's receiving-org membership, write-capable grant, grant scope, and project state inside the locked mutation. Read-only grants and out-of-scope project grants can still view allowed records, but they cannot change the application lifecycle.

Application and review lifecycleCopy Anchor Link

1. 1

   Applicant

   Draft project

   The applicant develops the live working set before any formal package is sent.

2. 2

   Shared boundary

   Submit package snapshot

   Submission freezes the exact document versions sent to the utility while preserving the project identity.

3. 3

   Utility

   Screen and review

   The review row moves through pending, queued, screening, screened, and notice states without changing the earlier snapshot.

4. 4

   Applicant

   Develop resubmission

   After a notice, the applicant changes the live working set in the allowed resubmission-development stage.

5. 5

   Shared boundary

   Resubmit a new snapshot

   A new immutable round returns to the utility queue as Pending. The utility selects Screen selected to review it; prior rounds remain available as history.

Source anchors: app/actions/application-submissions.ts, lib/db/utility-schema.ts

Viewing the QueueCopy Anchor Link

The queue table supports:

• Sorting — Click any column header to sort (application number, project name, status, date)
• Filtering — Filter by status or generation type
• Search — Search by application number, project name, or applicant name
• Pagination — Navigate large queues in pages of 50 rows

Batch Upload WorkflowCopy Anchor Link

To upload multiple applications at once:

Use the secure intake paths below. The former PDF-only base64 dialog is retired.

Upload packet (workspace v2)Copy Anchor Link

Upload packet starts one application without a CSV. Nothing is required up front: project name, application number, capacity, and connection level are all optional, and a blank application number gets a generated reference. The new draft opens on its Documents view so the files can be added immediately through the same secure intake. If the connection level or the program (for utilities that publish two or more) is still missing, the application's Overview asks for just that item; automated review cannot start until it is answered. Clicking Create twice, or retrying after a network error, returns the same draft instead of a second one.

Batch intake (workspace v2)Copy Anchor Link

After a refresh, open the application's Documents in the same browser tab and account to recover an already reserved upload. Reselect the original unchanged files if prompted; the same batch and child identities are reused, including a pinned CAD target. Accepted files are not uploaded again. Recovery does not retain file contents or signed credentials. Dismissing its local record does not cancel server work; use the individual cancellation controls where available.

A rejected new file selection shows an upload error without recovery controls. Correct the selection and try again. Retry Recovery is for account or saved-upload verification failures.

When utility-applications-v2 is enabled, Upload Batch uses secure document intake: the CSV manifest (required application_number; optional project_name, applicant_name, applicant_email, capacity_mw, generation_type, state, interconnection_level, program) creates one draft application per row, owned by the utility. Loose PDF, image, and DWG files are then matched to applications by filename prefix (Q-2025-001_deed.pdf → Q-2025-001; the remainder is shown as a hint only) and uploaded through the same secure intake developers use, one session per application. Document roles are assigned automatically and confirmed in the application's Documents view; Freeze package turns the documents into the immutable package that screening and notices work from. Utilities that publish two or more programs for a track must fill the program column with the program slug.

Triggering ScreeningCopy Anchor Link

To screen applications:

1. Select one or more applications using the checkboxes
2. Click Screen Selected in the toolbar
3. Each application starts one whole-packet review run in the utility lane (utility_screening), the same engine that reviews a developer's packet before submission
4. Status updates appear in real time as the run progresses

Formal-stage applications and the utility's own intake drafts (batch intake in progress) are eligible; developer drafts are not. A formal application in Pending, Queued, or Resubmitted moves to Screening when its review is queued, before work starts. It moves to Screened when the run completes. A failed start or run restores its previous status once no other utility review is active. These transitions also apply to authorized REST, SDK, CLI, and MCP screening starts, so the queue reflects reviews started outside the console.

A pending notice-delivery hold keeps the application status unchanged even when the run ends; resolve delivery through Notices. Salesforce imports use their connector-specific status path.

Re-screening preserves existing Screened, notice, and Complete states and their human decisions. An intake draft keeps its separate package-freeze transition, including automatic freezing where enabled. Each start counts against the same 50-reviews-per-hour limit as a single review. The result is reported per application: started rows leave the selection, and refused rows stay selected with the reason shown above the table. A utility that has not yet been onboarded for automated review sees Automated review is not yet available for this utility; its rows stay unchanged and notices stay manual. There is no fallback to the retired per-document screening pipeline.

For platform-submitted applications, screening happens against the same shared submission record the developer sees from their side. The utility owns the queue row, but the linked applicant can still see the lifecycle that belongs to that submission.

Document processing and AI review remain separate states. A failed or still-running current document artifact is not shown as reviewed merely because an older review completed. Resolve the current processing problem before relying on its findings or clean-review result.

Queue StatisticsCopy Anchor Link

The utility workspace context bar shows:

• Total applications in your queue
• Pending screening count
• Pending notices count

These values and the Notices navigation badge load when the Utility workspace opens, including when you follow a direct link to Screening, Notices, or Analytics. You do not need to open Applications first to refresh them.

For an applicant packet whose combined PDF has been human-confirmed and split, document counts use the derived child documents and exclude the retained source container. This keeps queue totals, readiness, review, and immutable package contents aligned.

CSV ExportCopy Anchor Link

Click Export CSV in the toolbar to download the current filtered view as a spreadsheet for offline analysis or regulatory reporting.

RelatedCopy Anchor Link

• Screening Pipeline — How the AI screening works
• Deficiency Notices — Creating and sending notices
• For Utilities — Utility workspace overview

Personal notificationsCopy Anchor Link

The utility workspace header includes a notification bell on desktop and mobile. When client-access notifications are enabled, eligible consultants can discover new grants there without reading email. The bell does not change the selected organization, application ownership, or review authority. See Access Grants.