Summer Verify one workflow end to end before expanding rollout. Use synthetic accounts for website and identity tests, and authorized records for operational verification. Keep the existing human support path available while testing.
Company and team access
- Confirm the selected company and the actor who is testing.
- Check that members cannot administer credentials or company knowledge, and that owners and admins see only the company records their permissions allow.
- Test invitation acceptance with the intended email; a different account must not inherit the invitation.
- Verify that operational viewing, investigation and approval permissions match the intended roles. Assignment alone must not grant approval authority.
- Confirm removal or revocation takes effect on a new request.
See Team and access.
Provider and vault checks
- Confirm company, environment and provider account before saving credentials.
- Check required provider reads using a known authorized record. A saved credential count is not a live connection check.
- Verify restricted permissions and any dedicated database reader with the responsible administrator.
- For Doppler, verify the config connection and each referenced secret. Vault access does not establish provider access.
- Inspect errors and history after rotation or disconnection. Removing a credential from Summer does not revoke the provider key or signed-in provider session.
- For Slack, inspect selected-channel grants and message, thread and attachment coverage separately from account verification.
Use API keys and Doppler and the provider reference.
Knowledge and workflow checks
Review the operating profile and relevant guides with their sources, dates and owners. Check the conversational role’s instructions and shared company knowledge. Test a routine question, an exception, a missing-evidence case and a clinical referral. Inspect the saved revision used by the new run or turn.
For operational work, compare a plan against original evidence. Check an approval preview’s exact targets and inputs, then verify execution with original receipts and readbacks. A completed run or a sent inquiry is not a resolved customer outcome. Keep automatic investigations within the agreed rollout restrictions.
Website messenger tests
Test the actual website, login and portal destinations on desktop and mobile before inviting customers.
Installation checks
- The installation belongs to the correct company and staging or production environment.
- Each embedded origin is listed exactly. An unlisted origin cannot open a session.
- The configuration appears before the loader script. A failed backend request shows a usable error.
- Clinician, sign-in, catalog and optional offer URLs reach the pages you intended on desktop and mobile.
Account checks
- Two accounts receive separate conversations and destinations, including accounts at different companies that happen to use the same account ID.
- A guest who types another person's name or email receives no access to that person's records.
- An expired login or failed verification produces an error instead of silently becoming a visitor.
- Login, account switching and logout refresh or revoke the widget identity and clear the previous account's draft and visible conversation.
- Replaying an assertion, changing its installation or nonce, or substituting a destination fails verification.
- An expired care context falls back to configured public links. A removed or disabled participant cannot keep reading or sending.
Link checks
Click the actual link from the widget. A signed-out patient should sign in and return to the intended conversation, plan or order. Your portal still verifies ownership on arrival; a Summer referral never grants access by itself.
Try an unrelated destination origin and an access-token URL in a staging assertion. Summer should refuse them. Do not put credentials, prescriptions, clinical messages or chart contents into link context.
Credentials and rollout
Store signing keys on your server. Keep separate installations and keys for staging and production. Rotate a key when necessary and expect current widget sessions to end. Do not log signing keys, bearer session tokens or signed identity assertions.
Connected operational tools have separate credentials and permissions. Start with the smallest access needed for the specific work. Public referral links and signed patient destinations do not require your EHR or billing API credentials.
Keep your normal support fallback available during rollout. An enabled installation is not evidence that every connected system or automatic action is ready.