Salesforce Utility ConnectorCopy Anchor Link

The retained credentialed connector is implemented in the review stack and disabled by default. The four REST, MCP, and SDK operations below are implemented; they are not a deployed or customer-enabled contract. Salesforce sandbox acceptance and separate activation approval are still required.

Salesforce remains authoritative for application answers, source files, and regulatory queue status. GridWonk captures exact review inputs and returns decision support. It does not approve applications, change their Salesforce queue status, or send applicant notices.

Source-managed lifecycle and package-freeze writes also refuse unresolved GridWonk notice delivery under the application lock. Pending, held or accepted-but-unfinalized delivery must be resolved first. This safeguard neither enables the connector nor adds a Salesforce notice action.

The protected Admin document-recovery implementation explicitly blocks source-managed projects. It cannot bypass Salesforce ownership, remote permissions, connector retry or result-delivery controls. No Salesforce endpoint, credential, import behavior or activation gate changes with it.

Installed applicationCopy Anchor Link

The installed-app pilot uses a different authorization model: Salesforce initiates every connection, GridWonk stores no Salesforce access or refresh tokens, and reviewers do not need individual GridWonk accounts. A Salesforce-held certificate authenticates a fixed approved test installation while Salesforce derives and checks the acting reviewer's identity and access. Layer 1 contracts and installation authentication are merged separately from the retained connector below. Layer 2 packet submission is approved and in progress, not complete or customer-ready. The installed-app API is hard-disabled; no existing connector flag, API key or OAuth token can enable it. A second unconditional gate blocks extraction, optical character recognition (OCR) and model review. The canonical plan's remaining approval gates still apply.

Layer 1 also carries the installation and Salesforce reviewer through the existing intake, review job and saved-package records without creating a GridWonk user. Ordinary document/result readers and direct authenticated database reads deny this mode, including staff access; the retained connector's recovery and result-delivery sweeps skip installed imports. An in-flight installed import stays valid across a connection policy bump that none of its own fences caused, using the same policy snapshot rule as the retained connector. Human and service actors on the retained connector keep their separate authorization and remote permission checks. Import creation uses a shared connection lock to avoid lock-upgrade deadlocks between concurrent imports; it still waits for an exclusive pairing change, so the two transports cannot race.

The separate Layer 1 Apex contract passed seven native check-only tests after the second review on September 16 (job 0AfQL00000rYdy80AC). It derives the org and reviewer, checks current record/field/file access, pins the exact PDF version, and shares its request-body fixture with TypeScript. The rerun also proved the review corrections: the emitted org and user IDs are the 18-character forms the server binds, and a compound field such as BillingAddress is refused in Salesforce rather than signed as an object the server would reject. Its public entry remains hard-disabled; these tests neither install the classes nor execute its certificate-signing lines. The later eight-test native checksum/contract check is also narrow evidence: it does not prove the whole Layer 2 configuration, private receipt, controller or browser workflow. Their source is now implemented, but integrated verification remains in progress. Neither result resolves the retained connector's per-user credential blocker described below.

Stage A demonstrated a valid 31,457,280-byte PDF read through Lightning Data Service and uploaded directly to private test storage, with matching independent hashes. A small newer version published during transfer did not replace the selected original bytes. Certificate-signed requests, rejection of unauthorized/replayed requests, upload recovery after page reopening, and private saving and reopening of signed synthetic findings passed. Removing the probe permission blocked subsequent result access. The test installation is inactive; no real packet review has run.

These fixed-source, single-page probes do not prove a full 12-file/120 MiB packet, production finalization, retention, customer pairing, multi-page history or managed-package installation. The 30 MiB file and 120 MiB packet requirements remain unchanged. James approved Layer 1 on September 16 and Layer 2 on September 17, with every existing approval gate retained. Signed results/history, retention/usage and packaging remain Layers 3–5, not built or approved by Layer 2. Production activation and real model processing require separate approval.

Layer 2 packet submissionCopy Anchor Link

Source services now validate the exact approved field/program/file manifest, create an import with its external Salesforce reviewer, reserve direct-storage upload attempts, and compare received bytes before acceptance. They reuse the existing source-managed revisions, private intake, accepted assets and review engine. No storage token or review job is created by preparation. An unchanged packet can reference an already committed current revision without creating another review or replacing its original reviewer attribution. The route dispatches preparation, upload authorization, finalization and read-only progress behind its unconditional gate; native/browser verification remains in progress. These source functions are not a live feature.

Apex reads the checksum of the exact Salesforce file version independently of the browser. Received size and MD5 are compared with that descriptor; received SHA-256 must also match the declared SHA-256 and becomes the accepted asset identity. MD5 is a consistency check, not strong proof against deliberately constructed checksum collisions. A browser-supplied matching SHA-256 alone is not independent proof of Salesforce origin. Security acceptance must retain this limitation.

The native receipt protocol saves a private Salesforce receipt before submission, keeps recovery tokens and upload-resource details privately in Salesforce rather than GridWonk, and rechecks current access before releasing them. Do not treat source or unit tests as proof of those native permissions. No Salesforce credential is stored in GridWonk, and large file bodies do not pass through its API. The native component provides selection/preview, receipt saving, reopening and continuing the same submission. Its permission set grants guarded Apex access, not direct access to private receipt objects. Hidden or closed pages clear the private view and in-memory credentials.

Retries preserve two active imports per installation, two outstanding uploads per import, six failed storage attempts and the original 24-hour processing deadline. A physical upload reservation is committed before signing and has a fixed conservative expiry of two hours plus 60 seconds; the actual token may expire earlier. A lost token response does not cause another token to be minted for the same reservation. Navigation may resume an unfailed attempt using its saved private token and resource. An explicit failure report counts once, permanently prevents that attempt's reuse, and keeps its physical slot until expiry. Reopening the record cannot renew budgets.

Every expected file must be independently accepted before extraction, OCR or review can be considered. Even then the separate compute gate refuses processing. Behind it, finalization uses the existing pipeline, commits only a complete revision, and freezes its completed review before marking the import completed. Read-only progress returns safe file/status metadata; it does not start or advance processing, reset limits or return findings. Dispatch uses the existing maximum of three processing retry cycles and a five-minute lease; it does not claim exactly-once execution. Failed storage-attempt limits and processing retries are separate controls. No real full-packet review, 30-day purge guarantee or package installation has been demonstrated by this Layer 2 source work.

The manifest declares salesforce-installed-app with installation-signature authentication and a planned REST binding. Salesforce signs small requests; PDF bodies use direct private-storage transfer. No new MCP, SDK, CLI or chatbot connection is part of this mode. Approval binds the utility, Salesforce org, deployment audience, program mapping and public key; the utility and platform approvals must come from two different administrators, and pairing requires the 18-character Salesforce org ID. Reviewers keep their Salesforce identity without receiving a GridWonk account.

Each signed attempt carries a nonce, a one-use request token. Retrying requires a fresh signature and token but keeps the saved submission identity and original deadline. Expired-token cleanup checks both application and database time, so waiting for a database lock does not incorrectly reject a valid retry. Replay protection and the durable request-rate limit remain enforced.

The rest of this page describes the retained credentialed connector, including remote Salesforce access, automatic processing and result delivery. Those behaviors are not part of the outbound-only pilot.

Implemented credentialed scopeCopy Anchor Link

• A manually requested review and automatic review after an approved ready-status change or relevant file/answer change.
• Individually linked reviewer accounts and separately granted service identities for automation.
• Multiple isolated Salesforce connections belonging to one utility organization each.
• Salesforce Files containing supported PDF, PNG/JPEG, DWG, or ZIP inputs.
• Internal review findings, field/file citations, revision history, and authenticated report links.

External file repositories, applicant access, AppExchange distribution, and editing Salesforce applications from GridWonk are outside this release. There are no in-app chatbot transport changes.

Prepare a pilotCopy Anchor Link

1. Identify the exact operating utility, state, interconnection program, and review-profile version. A parent-company name such as Xcel is not a review-coverage approval.
2. Supply a real utility sandbox and representative synthetic packet. Discover the actual object and field schema; there is no assumed Salesforce industry application object.
3. Approve versioned field mappings against a reviewed form model, including readable program filters, ready-status values, and file access. A typed name or checkbox is not signature proof.
4. Resolve the individual-reviewer credential blocker and pass native validation before installing the source kit. Then configure its private objects, permissions and separate credential lanes.
5. Complete the acceptance checks with the exact code, migrations, configuration, and authenticated browser sessions. Customer activation requires separate approval.

No deployment, database migration, customer credentials, purchase, or paid evaluation is authorized by these preparation steps.

The source kit is not an installed or sandbox-verified connector. September 15 check-only native validation accepted all 13 Apex classes after compiler/metadata repairs, but completed zero package tests: Salesforce rejects the legacy human credential's Custom plus PerUserPrincipal configuration. A supported per-user design is required; the shared automation identity must not replace it. The gateway now sends idempotencyKey and acknowledge: true, with a shared Apex/API fixture. Native package tests and Lightning acceptance remain separate requirements.

Account and permission boundariesCopy Anchor Link

The utility-owned packet repair preserves private.guard_salesforce_source_owner() unchanged: a Salesforce source packet must remain utility-owned with applicant_org_id IS NULL. Recording a developer's contact details does not link an applicant organization or grant developer access; future invitations must not populate that ownership field. Console-only packet-owner human confirmations add no Salesforce operation and do not activate either connector mode.

The utility account's Integrations tab has a Salesforce packet reviews card linking to Salesforce connections at /utility/integrations/salesforce. When the deployment switch is off, the page explains that the connector is disabled without querying its new database tables.

Utility owners and administrators configure connections, approve mappings, enable reviewers, and issue or revoke automation identities. Reviewers link their own Salesforce accounts. Interactive access requires both current utility membership and that person's current Salesforce source access; an automation account never substitutes for a failed employee authorization.

The utility Layer 3 REST/SDK/CLI decision bindings retain this source-access boundary. A definite source denial returns an opaque not-found response; an authorization-service outage does not become a successful read or decision. These bindings do not enable either Salesforce connector mode or authorize changes to Salesforce-owned evidence.

Automation grants are limited to the saved connection and approved program, with explicit operations and expiry. Newly issued service secrets are shown once. Stored Salesforce tokens are encrypted and never returned in setup responses, operation progress, or MCP results.

Adding or changing another reviewer does not interrupt unrelated imports or result deliveries. Saved work stops when its own actor, mapping, or service grant changes, even if that permission is immediately restored; request new work after approval. Turning automation off affects service work only. Disabling the connection affects all work. These rules do not replace live source permission checks.

Results require approved reviewer access and current source-record access. An old report link, utility administrator role, or private Salesforce record alone does not grant access. Applicant portal users are not eligible readers.

Generic packet, package-comparison, and document readers check current Salesforce permissions against every committed captured revision, including fields removed from today's mapping. This conservative rule can also deny the current view when an older field is no longer readable. Foreign review identities, malformed snapshots, and histories exceeding 200 revisions are refused; the authorization proof is never silently truncated. Ordinary non-connector reads are unchanged.

During a temporary Salesforce permission-check outage, mixed application lists keep ordinary applications and successfully authorized Salesforce applications available. A warning marks lists and counts as partial; unverified Salesforce applications are omitted from both. Refresh retries current permissions, without reusing an old access decision. Application-list database query failures still report an error, and a direct report or artifact read never returns unverified source data.

Snapshot and revision rulesCopy Anchor Link

Mapped answers preserve types and source object, record, and field references. Blank answers are different from denied, unmapped, unreadable, or invalid inputs. Connector access failures must not be reported as applicant deficiencies. A PDF-free application can use mapped field evidence; the connector does not fabricate a PDF or page reference.

The worker reads the full paginated file inventory and relevant fields twice, downloads exact ContentVersion IDs, and rechecks before committing the review inputs. This detects changes; it is not a Salesforce transaction spanning all those reads. Repeated changes end in source_changing without a partial review.

One source application keeps one GridWonk application ID. Confirmed removals leave the current packet while old package evidence remains intact. A failed or denied inventory is never a file removal. Ordinary GridWonk edits cannot change Salesforce-owned answers or documents. Revisions stop for staff review after adjudication or notice work begins; closed or withdrawn applications are never automatically reopened.

Every declared input must be transferred, processed, and resolved before the connector opens its independent review gate. Failed/expired upload batches or unresolved DWG pairing do not permit a partial review. A fully captured packet can still be reviewed for genuinely missing requirements.

The shared manual-review path separately refuses active, unexpired upload batches. Source revision or authorization failures retain their source-readiness explanation; they are not reported as an unfinished upload batch when no such batch exists.

After a completed review, the import worker freezes an immutable package before marking the import complete. It rechecks current connection, actor, mapping, grant, and packet authority under a lock, and requires the exact completed run and captured revision. A retry reuses that package after the same checks. Service-created packages retain a service identity, not a fabricated human user. This step changes no queue status, decisions, or notices.

The dependent utility-event layer adds utility.package.frozen to that existing transaction only when a new package is created. It preserves the exact stored import and review-job origin, checks that human, service, or installed-reviewer identity against current authorization, and refuses missing or inconsistent provenance rather than fabricating a user session. Reusing an existing package emits nothing new. Receiving-utility webhook subscriptions are separate from Salesforce's private result-delivery path; neither enables imports, write-back, or applicant notices. Connector activation and the utility-event schema/release gates remain separately held.

Limits and waiting statesCopy Anchor Link

The connector uses the existing intake and review budgets. It does not increase quotas.

quota_wait, capacity_wait, provider_throttled, processing_wait, and pairing_required explain why an operation is waiting. held requires staff attention. Retry the same logical request with its original request key; do not create repeated new requests to bypass a wait.

Result delivery also retries temporary authorization-check outages, up to ten attempts. Every attempt confirms current access before calling Salesforce. Revoked access cancels delivery.

Disabling a connection blocks new and queued work and stops a running worker at its next safe authorization checkpoint. Captured evidence is retained under existing retention rules. Re-enabling does not silently restart cancelled work.

Authenticated interfacesCopy Anchor Link

The console's packet-cancellation control and the ordinary job-cancellation lifecycle repair add no Salesforce operation or permission. The four connector bindings below, source-managed import restrictions and separate activation gates are unchanged.

All four bindings use the same connection-scoped services. Reads require partner.read or connector read authority; import requires partner.write or connector write authority. A connector service token is bound to its connection and REST or MCP resource audience. Approved human OAuth clients use only the narrow MCP tool set; an MCP token cannot be reused on REST. Every request also checks current source permissions and organization access, rate limits, and usage policy.

The shared capability manifest also records the bounded evaluation-dispatch contract. Refusing unapproved paid evaluation does not change these four Salesforce operations, quotas, or pilot gates.

The shared capability manifest also declares the Prompt Ops source-catalog workspace, while the SDK exposes read-only prompt history. Removing direct prompt mutations does not change these four Salesforce operations or their activation, connection, and source-permission gates.

The REST base is /api/v1/integrations/salesforce/{connectionId}:

Reuse the same idempotency key after an uncertain import response; the SDK does not automatically retry this POST. Inputs cannot override the actor, utility, credentials, or connection path. Responses are private and non-cacheable. Documentation and discovery still require sign-in. The setup page is available; a separate packet-search/import browser interface remains planned.

Agentforce calling GridWonk and an existing MCP client calling Salesforce's hosted MCP server are separate configurations. Both need sandbox compatibility tests. Connection administration, permission changes, manual package freezing, adjudication, deletion, and notices are not connector MCP tools.