The short answer
Connect a specific CRM event to a saved mailing intent, generate a PDF from approved fields, and put it in a review queue. After a person approves the recipient, document, price, and purpose, submit one IRIS mailing. Keep event handling and deduplication in your own application.
Pick an event with a clear customer benefit
A completed service visit, an approved request for a paper confirmation, or a new client handoff can justify an individual letter. The trigger should explain why the recipient needs the document. Avoid treating every contact update as permission to send correspondence.
For an illustrative workflow, imagine an account manager marking a project “completed and reviewed.” Your integration creates a draft completion letter and assigns it back to that manager for review. The manager can correct a contact, update the next step, or decline to mail it. No customer results or conversion lift are implied by this example.
Map CRM fields to a mailing record
Use explicit field mapping. CRM contact records often mix a person’s name, company location, billing address, and previous address. Decide which fields represent the intended postal destination for this document.
| Source | Application record |
|---|---|
| Stable source event ID | Unique mailing intent reference |
| Approved contact and postal address | Recipient snapshot for review |
| Final document facts or exported PDF | Document version and registered IRIS ID |
| Assigned account manager | Reviewer and approval timestamp |
| IRIS submission result | orderId and last observed mailing status |
Use a queue between the webhook and mailing API
When your CRM emits an event, validate its authenticity using that CRM’s documented mechanism and save the event before processing it. Respond to the CRM according to its integration contract. A separate worker can prepare the document without keeping the inbound webhook request open through PDF generation and review.
Add a unique constraint for the business event so redelivery does not create another intent. If an event arrives out of order, reload the current source record before drafting. Put missing names, incomplete addresses, and conflicting records into an exception queue your team can see. IRIS does not supply this CRM orchestration layer for you.
Make review useful, not ceremonial
Show the source event, final PDF, sender, recipient, mailing options, and price in one review. A button labeled “approve” is not enough if the reviewer cannot see what will go into the envelope. If the PDF changes, invalidate the old approval and register the replacement before obtaining a new quote.
A preparation worker can have documents:write and mailings:read scopes, alongside account:read. Keep mailings:write with the trusted approved-submission component. Save the idempotency key before calling the mailing endpoint, then attach the resulting orderId to the CRM record or your own integration record.
Write back status carefully
Use GET /v1/mailings/{id} to obtain current status and available tracking. Label the CRM fields plainly: “mailing order created,” “last observed status,” and “last checked at.” Do not overwrite a customer’s service completion state with the mailing state, and do not label a paid order as delivered.
A useful first rollout handles one letter type and one reviewer group. Track the number of source events, prepared drafts, approved mailings, rejected drafts, and unresolved exceptions. Those counts reveal whether the automation is behaving as intended before you expand its responsibilities.
Sources & further reading
Product details checked against the IRIS API contract when this article was published. Platform references can change; consult the linked documentation when implementing.
Published by IRIS Postal Forms, operated by Great Lakes Computing Office LLC. Send a correction.