Service Cloud for agencies · renewals
A renewal you hear about from the client is already late.
Three tasks on the policy, at 90, 60 and 30 days.
Renewal reminders in Salesforce are three tasks created from each policy’s expiration date, for the account manager who owns it: at 90 days request loss runs, at 60 days market the account, at 30 days present the options. They work only when the policy record and its date can be trusted, so most of this article is about what breaks them: dates, policies loaded from the agency system, and duplicates.
Reviewed 1 November 2026.
The mechanism
How do 90, 60 and 30 day renewal tasks work in Salesforce?
A Policy record holds the expiration date and an owner. Automation compares the date with today and creates a task for the owner at 90, 60 and 30 days before it, each with a fixed subject and a due date. When the renewed policy is entered, the old one is set to Renewed and creates nothing more.
Each task asks for the work that has to start by then, not for a reminder to think about it. The subjects and offsets below are where an agency usually starts; kept as custom metadata records, the administrator changes them without a developer.
| 90 days before expiryRenewal: request loss runs and updated application. Due in 7 days. | 90 days |
| 60 days before expiryRenewal: request MVRs and market the account. Due in 7 days. | 60 days |
| 30 days before expiryRenewal: present options to client. Due in 7 days. | 30 days |
The choice that decides the rest
Which kind of automation should create the renewal tasks?
Salesforce offers two. A scheduled path waits from a date on the record; a schedule triggered flow runs once, daily or weekly over all matching records. When policies arrive in bulk from the agency system, a daily sweep that creates any missing task is the safer choice, because it does not depend on when each record was saved.
Both are documented on Trailhead: scheduled paths count minutes, hours, days or months before or after a field on the record, in the unit on scheduled paths, and schedule triggered flows run once, daily or weekly in the unit on scheduled flows. Neither page says what a scheduled path does when its moment is already in the past at save time. That is the case an import creates every time.
- 01
What starts it
Scheduled path: a change to the policy record, then a wait counted from its expiration date. Daily sweep: a fixed time every morning, over every Active policy that expires in the next 90 days.
- 02
A policy imported with 45 days left
Scheduled path: the 90 and 60 day moments are already past at save time; test what your org does with them before you rely on it. Daily sweep: the first morning creates the missing 90 and 60 day tasks, due today and marked late, instead of nothing until day 30.
- 03
The expiration date is corrected
Scheduled path: check in your org that the wait follows the new date and that no task is created twice. Daily sweep: the next morning simply reads the new date.
- 04
How you test it
Scheduled path: Debug, choose the path, skip the start conditions. Daily sweep: run it in Debug against two test policies, 91 and 31 days from expiry, and count the tasks.
The sweep’s rule fits in one sentence: every morning, for each Active policy that expires within 90 days, create each renewal task whose day has come and which does not exist yet on that policy. One rule covers new policies, imported policies and corrected dates. If you use a scheduled path instead, Trailhead notes it runs as the Default Workflow User set in Process Automation Settings; check who that is before the first renewal is due.
From a build
What a daily sweep looked like in an agency org.
In the trucking insurance agency I built Service Cloud for, the policy book stayed in Applied Epic, so renewal tasks on the agency’s own policies were not part of that build. The expiration date still drove two pieces of automation on the sales side, where it is the date a prospect’s current policy with another agency ends.
The first was a schedule triggered flow on Lead that ran every morning at 08:00 UTC, before the team in the US started. It read every open lead with an expiration date, and when the date had passed it moved the lead to a queue named “Processing period has expired” and set it to Unqualified, so nobody chased a renewal that was already lost. Its decision element was labelled “10 days ago” while its formula was today minus one day. Read the formula, not the label.
The second tied each opportunity to a planned goal for the month in which the prospect’s policy expires: one goal per person per month, rerun whenever the owner or the date changed, and a batch that recalculated every existing opportunity once. The lesson carries straight to renewals: a date that drives work has to be rechecked when it changes, not only when the record is created. The whole agency build is in the case study.
What breaks them
Five ways renewal tasks fail without an error.
Run this in the Developer Console query editor on a Policy object like the one described here; rename the fields to yours. Any number above zero is a policy that will never produce a renewal task.
- 01
Dates that are empty, wrong or swapped
An Active policy with no expiration date creates no task and raises no error. A date loaded with day and month swapped creates the right task in the wrong month. After every import, open five policies whose day is 12 or lower and compare them with the agency system, then run the query above. Both counts should be zero.
- 02
Policies loaded from the agency system
Decide in writing what a renewed term is. Either the same Salesforce record with a new expiration date, or a new record with the old one set to Renewed. Mixing the two gives you a policy that asks for loss runs twice, or not at all. Load with a unique key of policy number plus line, so a second import updates instead of adding.
- 03
Duplicates from two writers
Two automations that both create renewal tasks, or one that runs twice, give the owner twins. Before creating a task, look for an open task on the same policy with the same subject. A duplicate policy record does the same thing at the policy level, which is why the unique key comes before the first task.
- 04
A task for somebody who has left
The task goes to the policy owner. When an account manager leaves, their open renewals stay with them unless the book is reassigned. Add a weekly list of open renewal tasks owned by inactive users; it should be empty.
- 05
A cancelled policy that still says Active
Renewal tasks for a policy the client cancelled waste the account manager’s time and teach them to ignore the tasks. Cancellation has to set the Salesforce status too, as a step nobody can skip, not as something somebody remembers.
Asked often enough to answer here
Questions
- Q
Should the reminder go to the client by email instead?
Start with tasks. A task makes one person responsible for the renewal; an automatic email to the client only tells them a date. Once the tasks are done on time, add a client email from a template the agency approved, sent by the account manager or after the 60 day task closes.
- Q
Can the agency change the days or the wording itself?
Yes, if the task list is kept as records. A custom metadata row per task holds the days before expiry, the subject and the days until due. The administrator edits a row in Setup and the next policy follows it, with no developer and no deployment.
- Q
Do the policies have to be in Salesforce for this?
Yes. The tasks are created from the expiration date on a Policy record, so the policies come first: one import from a spreadsheet exported from the agency system, matched to clients by their client code. Keeping them current after that is a separate decision.
Renewals are 33 to 40 hours, €2,145 to €2,600, and need policies in Salesforce first: 28 to 35 hours, €1,820 to €2,275. Both are priced stage by stage on the insurance agency page, and they can run before the inbox work if renewals hurt more.
Serhii Skrypnyk · Senior Salesforce Administrator · 7 Salesforce certifications · on the platform since 2018. Reviewed 1 November 2026.
Read next
The question that usually comes after this one.
- 01
Financial Services Cloud vs Service Cloud
For an insurance agency on Applied Epic: licence prices side by side, what the FSC insurance data model holds, and when a light Policy object is enough.
- 02
Applied Epic and Salesforce: Who Holds What
An agency on Applied Epic adding Salesforce: what stays in Epic, what moves to the service desk, and how clients and policies cross over without an integration.
- 03
Case: Insurance agency, United States
Client service moved from shared inboxes to queues: every email a case with one owner, the request type read from the message, policy changes that cannot skip a step, Applied Epic kept.