Service files, email and integrations
These service settings connect a journey to file storage, messages and operational alerting. They should be configured with the library owner and tested in QA using representative, non-sensitive data. Keep credentials and connection details in protected library configuration, not in page content or templates.
Use the library connection, not an ad-hoc destination
The service selects from storage connections configured at library level. The underlying storage type and site link are system-managed choices: do not edit their internal values through an API or workaround unless directed by product support. Instead, create or update the named connection in library settings, then select it in the service or relevant action.
For file uploads, agree these decisions before building the action:
| Decision | What to define |
|---|---|
| Destination | Which approved QA and production connection receives files. |
| Folder structure | A stable, non-sensitive parent path that supports retrieval and retention. |
| File types and limits | What people may upload and how invalid files are handled. |
| Permissions | Who can read, edit or remove stored files. |
| Retention | How long files are needed and who is responsible for disposal. |
Test a successful upload, rejected file, unavailable destination, repeat submission and authorised retrieval path. The person should receive a clear next step when an upload cannot complete.
Configure emails for the right environment
Service-level email provider and address overrides are most useful for controlled testing and exceptional service requirements. An Email to address override can direct all messages to a safe test mailbox; an Email from address override must be verified by the chosen provider; an Email reply-to address override must reach a monitored support route.
Never leave a QA override in place when deploying a production version. Keep addresses purpose-led and make it clear who responds to replies. Check that emails are understandable without the context of the browser page and that they do not expose unnecessary personal information.
flowchart TD
A["Action needs to send a message or upload a file"] --> B["Select approved library connection"]
B --> C["Configure service or action setting"]
C --> D["Use safe QA destination or mailbox"]
D --> E["Test success and failure paths"]
E --> F["Review production settings before deployment"]Alert on action failures without exposing data
Action failure alert emails can be configured to alert on every failed action or only selected action IDs. Use selected alerts for high-impact operations such as a critical data update, document transfer or message dispatch. Name actions clearly so an alert immediately tells the team what failed.
Including the full payload in alert emails can help diagnose an issue, but it can also expose answers, uploaded-file metadata or sensitive operational data. Leave payload details out unless there is an approved need, a protected recipient group and a documented handling process. An alert should contain enough context to begin investigation without becoming another uncontrolled data store.
| Alert test | Expected result |
|---|---|
| Selected action fails | The appropriate operational mailbox receives a useful alert. |
| Unselected action fails | No alert is sent when selective alerting is intended. |
| Action succeeds | No failure alert is generated. |
| QA failure | The alert and any payload go only to authorised test recipients. |
| Production failure | The responder can identify the service, action and next investigation step. |
Keep external actions dependable
The action itself controls how a file is uploaded, a list is read or updated, an external endpoint is called, or a message is sent. Service settings establish the shared configuration around it. Sequence dependent actions carefully and use conditions to avoid an unnecessary call. For a list update, look up the target item before an upsert so the service can identify it correctly.
External systems can be slow, reject data or be unavailable. Give people a recoverable route, set realistic timeouts, test malformed and missing responses, and ensure a retry cannot create unwanted duplicate records or messages.
Pre-deployment review
- Confirm the library connection and target environment.
- Check that QA and production destinations are different where required.
- Verify sender and reply-to addresses.
- Check action IDs selected for alerting and authorised recipients.
- Test a representative message or upload from a fresh QA journey.
- Confirm no temporary override, credential or sample personal data remains.