Treat the connection as a requirement to prove
An authentication incident belongs in a service process, but the existence of a PSA product does not establish an EmailAuth integration. This guide specifies a proposed ConnectWise PSA workflow: associate evidence with the right customer, create or update the intended work item, assign responsibility and retain a defensible closure decision. No ticket was created, no API call was made and no customer system was inspected.
Public first-party material was reviewed on 8 November 2026. The current ConnectWise PSA product page describes service workflows, time tracking and SLA monitoring. It is not a version-pinned API contract. The PSA developer documentation landing page required login, so endpoint schemas, authentication details, permissions and supported version behavior remain unverified. The linked public FAQ returned 404; no bypass or registration was attempted.
Establish the supported interface before designing writes
ConnectWise's Getting Started guidance explains that documentation access depends on registration approval and distinguishes product-specific integration interfaces. An authorized implementer must obtain the applicable PSA documentation and record the product version, service location and supported operations. Do not copy a request body from an unrelated connector or assume an Automate example applies to PSA.
Create a contract checklist for ticket creation, evidence notes, assignment, status changes, retrieval and error handling. For each operation, record required fields, permissible values, pagination, response semantics and limits from the actual contract. Unknown entries stay unknown. This article intentionally supplies no executable endpoint, credential recipe or payload that might falsely imply those checks have been completed. Access provisioning and customer-data transmission need separate approval.
Resolve customer identity before routing the incident
Use a maintained mapping between the authentication customer, the exact domain or subdomain and the PSA company or account identifier. A similar display name is insufficient. Shared mail providers, acquired brands and delegated subdomains can create plausible but wrong matches. If more than one customer could own an observation, hold it for a human decision rather than creating a ticket in whichever account appears first.
Specify the destination service board, relevant ticket classification, responsible team and escalation owner using the customer's configured values. ConnectWise's ticket escalation article, dated 8 March 2019, describes boards, templates and workflow rules. It provides historical workflow context, not proof of today's tenant configuration. Status names and board visibility must be verified in the target environment before any implementation is enabled.
Separate an observation from a service incident
A report row, a failed authentication result and a customer outage are not interchangeable objects. RFC 9990 defines aggregate reporting data that can cover multiple messages and reporting periods. Decide which evidence pattern warrants investigation, how its severity is assessed and when another observation should update an existing incident instead of creating a fresh ticket.
A proposed correlation record could combine the customer identifier, sending identity, incident category and bounded observation window, while retaining original report references separately. It must not merge unrelated customers merely because they use the same IP address. Repeated evidence should remain attributable even when grouped. A later change in cause or ownership can justify a separate incident with a link to the earlier investigation.
Keep evidence useful without spreading it unnecessarily
Design a minimum ticket summary containing the affected stream, observed period, relevant authentication finding, uncertainty, proposed next step and an access-controlled evidence reference. Avoid attaching full message bodies, credentials or unrestricted report archives by default. Review who can see the board, notes, portal and notifications. An internal-looking field is not a privacy guarantee until its actual behavior has been checked.
Preserve the source observation and the interpretation as separate entries. The record should show who reviewed an inference and which evidence version they saw. A signed evidence link can expire or grant wider access than intended, so verify its recipient scope and retention behavior. Posting information to ConnectWise is an external disclosure even when the originating analysis was read-only; the permitted data and destination must be explicit.
Reconcile uncertain writes rather than multiplying tickets
Plan for a request that times out after the server may have accepted it. A local timeout does not prove that no ticket exists. The proposed worker should retain its correlation identifier, inspect the permitted destination state and reconcile before repeating a creation attempt. Do not claim ConnectWise supports an idempotency mechanism until the current documentation and controlled tests establish that behavior.
Define bounded retries for recoverable failures and a human queue for unresolved outcomes. Authentication failures, invalid mappings and schema errors should not trigger uncontrolled retry loops. If ticket creation succeeds but the evidence note fails, preserve that partial state and avoid reporting a fully recorded incident. A retry must not overwrite a technician's later assignment or a customer-specific closure decision with stale event data.
Close the investigation with evidence, not a quiet feed
A proposed lifecycle moves through intake, ownership review, investigation, approved remediation, verification and closure. Those are design labels, not guaranteed built-in PSA statuses. Silence in a report feed can mean delay, loss of visibility or a stopped sender; it is not sufficient proof of resolution. Closing a ticket must identify the verification evidence and the person responsible for accepting the result.
The intake gate remains exact and unmet: Verify the target system API and workflow. Do not imply EmailAuth has an unverified integration. The original-evidence requirement is: Run a ConnectWise-specific test incident, retry and closure lifecycle using current documentation. That future authorized test must include duplicate intake, an uncertain creation response, a partial update and a reopened incident. DNS changes, credential setup and customer communications remain separate approvals. This manuscript is preparation for that demonstration, not the demonstration itself.