Scheduling Requests
There are two different things people mean by scheduling. One you do yourself on the request form. The other we set up for you.
Deferring a single request
Every request form carries a date/time field in UTC. Set it to a future moment and the request sits unprocessed until that time passes.
That one field is what makes it possible to queue work in advance: submit several requests now, each with a different start time, and they begin on the days you chose rather than all at once.
Why you would want to
An AutoMerge request against a large backlog of duplicates can run for hours. A long enough run drifts into your CRM's maintenance window overnight and times out there.
Rather than one long request, submit several, each scheduled for a different day, each with a stop time set to halt cleanly before your maintenance window begins. See Manage the maintenance window for your environment to look up or change when yours runs.
A stopped request does not resume. The next day's request is a separate job that picks up whatever duplicate sets remain unmerged, working from highest precision downward. Nothing is lost; the work simply continues.
Setting it up
- Decide how many evenings of merging you want to queue.
- Submit one AutoMerge request per evening.
- On each, set the UTC start date/time to that evening.
- On each, set the stop time to end before your maintenance window.
Remember the field is UTC, not your local time. Converting wrong is the most common mistake here.
Recurring schedules
Deferring a request handles a known backlog of duplicates. It does not give you a standing monthly analysis.
Recurring schedules are a different mechanism, and AutoMerge support sets them up for you.
How it works
- You run a request the way you want it repeated. The Analysis Rules, connection, operation, and settings all set the way you want them.
- Tell us to make it recurring, and at what interval: weekly, monthly, quarterly, or whatever fits your data.
- We use that request as a template. From then on, matching requests are created and submitted automatically on your interval.
You don't configure or maintain anything. New requests appear and run on schedule, and you review the results as they arrive.
What it's good for
Duplicate prevention is not a one-time project. New duplicates arrive continuously through manual entry, imports, and integrations. A standing monthly Analyze/Tag pass keeps the backlog of duplicates from accumulating quietly.
A common pattern: clear the initial backlog of duplicates once with scheduled AutoMerge requests, then move to a recurring monthly Analyze/Tag so the ongoing volume stays visible and small.
Recurring scheduling isn't self-serve. Get the request right once, then contact us with the interval you want.
Which one you need
| You want to | Use |
|---|---|
| Split a big merge job across several nights | Deferred requests, set by you |
| Avoid a maintenance-window collision | Deferred requests with a stop time |
| Analyze automatically every month | A recurring schedule, set up by support |
| Keep duplicates from accumulating after cleanup | A recurring schedule |