EXXAS

Removed from the group, and still being written to

Membership is settled in the address management system. Who belongs to which group, who has joined, who has been taken out. That is where it is maintained, and that is where it is right.

A day later it is right in the mail system too – as long as somebody only joins. Removals are the problem. Anyone taken out of a group simply fails to appear in most synchronisations. They are no longer delivered, so they are not touched, so they stay in the list. And keep receiving mail from a group somebody deliberately took them out of.

The EXXAS interface to Caymland M4 carries both directions. What is new is added. What is no longer delivered is removed.

What is transferred

The groups are the real value. They are held in Caymland as memberships and can be used in segments, campaigns and reports without anyone maintaining them a second time.

Why removals have to come along

A synchronisation that only adds grows more wrong over time. It grows, but it does not correct. After two years the list holds a membership that has not existed in the source for eighteen months, and nobody can say which one.

The delivered file therefore counts as the complete truth for that client. It is read once and used for both directions: enter what is new, and remove what it no longer contains.

That is not a technical detail. It decides whether a send to a group reaches the people who belong to it today, or the people who belonged to it at some point.

The safeguard against the half download

An interface that deletes on the basis of a file is only as good as its distrust of that file. If the delivery arrives truncated – an abort, a timeout, an error on the far side – it does not say "fewer memberships", the rest is simply missing. Applying that unchecked empties your data.

So a comparison happens before anything is removed. If the delivery holds less than four fifths of what we already carry, nothing is removed. The case is recorded instead. The additions still go through, because they do no harm in any event.

In practice that means: a failed run costs currency until the next run. It never costs the data.

How the connection runs

Direction: from EXXAS to Caymland M4. Nothing is written back. Your address management stays the authoritative place, and it stays unchanged.

Access: per client, with its own credentials. Every access is confined to its own data, and the interface works strictly within that boundary.

Rhythm: on a schedule. The data is as current as the last run.

Large volumes. Deliveries are read as a stream and processed in blocks rather than loaded whole into memory. That is why six-figure membership lists run through instead of failing at a limit.

No double run. A running import is detected. If the schedule starts again while the previous one is still working, the second waits rather than colliding with the first.

What you need

On the EXXAS side:

• Access to the interface with user and password
• Release of the areas you want to draw

On the Caymland M4 side:

• Activate the integration and store the credentials
• Define the field mapping once
• Set the schedule

The group structure is taken over on the first run. You do not have to prepare anything for it.

What this looks like day to day

The group send. An email to a group goes to today's composition. Not to the one from two years ago, topped up with everyone who has joined since.

The departure. Somebody is taken out of a group in the address management system. At the next run they are out in Caymland too, and the next send goes without them.

Maintenance in one place. Addresses are maintained where they belong. Caymland reflects what is there instead of building a second set that nobody reconciles in the end.