Vendor Routing & Maintenance-Request Data Handling
A plain-language reference for whoever reviews JP Works before any live data is connected. The Vendor Routing Desk drafts vendor outreach and tenant acknowledgments from inbound maintenance requests. This covers what it touches, where it runs, how it is secured, and the light approval the scope needs. Lease-renewal drafting is named here as a later phase, with its heavier approval, so the line is clear.
The routing desk touches operational data only: your preferred-vendor list and inbound maintenance requests. It clears with IT-issued, read-only access and a light data-processing agreement covering the tenant contact details inside a request. Until both are in place, everything runs on synthetic (fabricated) data, with zero access to your systems. Lease and rent data are out of scope here and would raise the bar (see section 5).
What the desk reads, and what it never does
The desk reads a narrow slice of operational data to produce a draft. It never modifies a system of record and never sends on its own.
| Data | Used for | Access |
|---|---|---|
| Preferred-vendor list | Match the request to the right vendor by trade; draft the outreach | Read-only |
| Inbound maintenance request | Pull the unit, the issue, and access details out of the email | Read-only |
| Tenant contact (name, unit, email/phone) | Address the acknowledgment and time the follow-up | Read-only |
| Vendor outreach (output) | Written to the manager’s drafts folder for review | Draft-only |
| Tenant acknowledgment (output) | Written to the manager’s drafts folder for review | Draft-only |
- No lease or rent data. Leases, rent rolls, and renewal terms are out of scope for the routing desk. The automation never reads them.
- No autonomous sending. Every output is a draft a person reviews and sends.
- No writes back to accounting, lease, or CRM systems of record. Output is email drafts, nothing else.
- No payment-card or banking data is accessed (no PCI scope).
- No tenant-selection or screening decisions. Out of scope, which keeps fair-housing rules out of play.
Where the data goes, and where it doesn’t
From the very first live record, the workflow engine runs in a dedicated, single-tenant cloud environment that JP Works operates as your named subprocessor, on infrastructure from a SOC 2-attested provider. Your data is isolated from any other client, pinned to a single US region, encrypted throughout, and never exposed to a public model API. JP Works is named in the data agreement as the subprocessor, so the path is disclosed and contractually bound, not hidden.
Access is granted the simple way. Read-only viewer access to the vendor list, and a read-only view of the request inbox (a forwarded label or a mailbox delegation), both using your own accounts so they revoke in a click. Nothing new to stand up, and no standing credentials for your team to manage.
The AI layer runs through the infrastructure provider’s enterprise AI service. Per the provider’s published terms, customer prompts and completions are not used to train foundation models and are not shared with the model maker, which has no access to that traffic. Invocation logging is customer-controlled and can be disabled, and inference is pinned to a US region for data residency. The provider and model are named, with primary sources, in the client-specific brief and data agreement.
The controls in place
- Not used for training. Per the platform’s published terms for hosted models, your prompts and completions are not used to train the model and are not shared with the model provider.
- Not retained outside the environment. Invocation logging is controlled at the account level and can be disabled, so no working copy persists outside the dedicated environment.
- Region-pinned residency. Inference and storage stay in a single US region fixed for the engagement.
- Encryption everywhere. TLS in transit; managed (or dedicated-key) encryption at rest.
- Least-privilege access. Read-only, scoped to exactly the vendor list and request fields the desk needs, with no broad data access.
- Full audit trail. Every run is logged (what ran, when, on which request) via the workflow engine, reviewable on request.
- Intermediate-data purge. Working data used to assemble a draft is purged on a fixed schedule set in the data agreement, not warehoused.
- Revocable on a day’s notice. Read access is granted via credentials your team issues and can revoke at any time; on termination, client data is deleted per the data agreement, and on request.
- Incident notification. If a data incident affecting your data is identified, you are notified without undue delay. The controlling terms are set in the data agreement.
- Scoped operator access. JP Works personnel access is itself least-privilege, logged, and revocable by your team; build and tuning happen against synthetic data, not live records.
- Dedicated, SOC 2-attested infrastructure. The engine runs on cloud infrastructure from a SOC 2 / ISO 27001-attested provider, in a dedicated, single-tenant environment isolated from any other client and named as your subprocessor in the agreement, so the path is disclosed and contractually controlled. JP Works itself is not separately SOC 2 certified; the attestation is the underlying platform’s.
What rules this is built to satisfy
The routing desk’s data is operational, not a trade secret, so the framework is lighter than it would be for lease data. It is mainly a combination of state privacy law and standard vendor-security expectations:
| Framework | Why it applies | How this design meets it |
|---|---|---|
| CCPA / CPRA (California) | A maintenance request carries tenant personal information processed for a business purpose | JP Works acts as a “service provider”: purpose-limited, no sale, deletion on request, via the data agreement |
| Vendor security (DPA + SOC 2) | Standard third-party-risk requirement | Entity-level DPA; runs on SOC 2-attested infrastructure (JP Works itself is not separately certified) in a dedicated single-tenant environment; JP Works named as subprocessor |
| Minimum-necessary access | Tenant PII should be read only as far as the task needs | Read-only, scoped to the vendor list + request fields; no broad data access; intermediate data purged |
| Expanded scope · renewals | Leases and rent rolls are a different class of sensitive | Not in this scope. Adding renewals raises the bar: leadership sign-off and a heavier data agreement before any access |
The routing desk is privacy-law work, not trade-secret work, so it clears with IT and a light agreement. It is still held to the same retention and audit rigor, because tight controls cost nothing to keep and make expanded scope easy to approve.
Three pillars, in order
1 · Synthetic demo
Capability proven on a fabricated vendor list. Zero access to your systems, nothing to authorize. Establishes that it works before any real data is involved.
2 · IT access + light DPA
JP Works reviewed as a vendor: this brief + a light data agreement + IT-issued, read-only access to the list and the request inbox. The point where your controls attach.
3 · Live desk
Drafts run against your real list. Least-privilege, region-pinned, audited, revocable. Draft-only throughout, a person reviews and sends.
Once the routing desk proves out, the natural next step is drafting lease renewals, one of the bigger time sinks. Renewals pull lease and rent data, which we treat as a different class of sensitive, because it is. That tier deliberately raises the bar: leadership sign-off on scope and a heavier data agreement before any lease is touched. It is named here so the line between the two is clear, not blurred.
Where these claims come from
The regulatory statements above are drawn from primary sources. The platform claims (training, retention, residency, attestations) are drawn from the infrastructure provider’s published terms; the provider is named, with a link to every source, in the client-specific brief that accompanies vendor review.
| Claim | Primary source |
|---|---|
| CCPA / CPRA service-provider duties | oag.ca.gov/privacy/ccpa |
| Platform terms: training, retention, residency, SOC 2 / ISO 27001 | Named and linked in the client-specific brief + data agreement |
A client-specific version of this brief, with the platform named, every source linked, and the named-subprocessor list, is provided during vendor review along with the data-processing agreement. Request it at justin@jpworks.io, or start with the Vendor Routing Desk.