ValueText ValueText
Salesforce Use case · Finance · Invoice

Confirm the payment, then remind gently, and be able to prove both.

One flow fires on payment received. A scheduled flow handles what is due and what is late. Both write back to the invoice, so Finance and Support read the same history instead of chasing it across tools.

ObjectInvoice, or your payment record
Fires onPayment received, and a daily due-date sweep
Reply landsCase, linked to the invoice
ChannelSMS or WhatsApp, by contact preference
01 · What quietly breaks

The risk is not forgetting to send. It is not being able to prove what you sent.

Most teams get as far as sending reminders. What breaks is everything around them: the message is not linked to the invoice, so nobody can trace it later. The timing lives in a spreadsheet, so a changed due date quietly stops working.

Replies land in somebody's personal inbox instead of a tracked work item, and the follow-up is missed. Consent and opt-outs are handled differently by each person doing the sending.

Then a customer disputes a charge, and the question is what they were told and when. If the answer is in a phone, it is not an answer.

02 · The idea

Keep the process where the record is. A change in Salesforce sends the message, Salesforce decides who and what, and the message is logged back to the invoice it belongs to.

03 · The pattern

Two automations, kept separate on purpose.

A confirmation is immediate and unconditional. A reminder is scheduled and conditional. Merging them into one flow is what makes reminder logic unreadable six months later.

01

Confirmation, the moment money lands

Fires when the payment is marked received. It finds the contact linked to that payment, sends a short confirmation with the amount and the next due date, and writes the message and its delivery status back to the record.

This is the one that pays for itself in avoided calls, and it is also the one that settles a dispute later.

In Salesforce Flow typeRecord-triggered, payment record, after saveEntryStatus → ReceivedTemplatePayment_ConfirmedWrites backMessage Bucket on the invoice, delivery status
02

Reminders, on a schedule and in a sequence

A daily scheduled flow checks what is due and what is overdue, and sends at most one message per invoice per stage: a friendly note a few days before, a short nudge the day before, and a polite line the day after if it is still unpaid, inviting a reply to reschedule.

The stage stamp is what keeps it gentle. Without it, a changed due date re-triggers the sequence and the customer gets the same reminder four times, which is how a payments channel gets muted.

In Salesforce Flow typeSchedule-triggered, dailyStagesDue minus 3, due minus 1, due plus 1StampLast_Reminder_Stage__c, Last_Reminder_Sent__cSuppressSkip if a reminder was sent within the cooling period
03

Escalate to a person, only when it is needed

Past the last stage, the flow stops messaging and creates a Case for the collections queue with the thread attached. Nothing after that is automatic, because the conversation after a missed payment is not one to automate.

In Salesforce TriggerOverdue past the final stageCreatesCase, queue = Collections, linked to the invoiceAttachesThe full message threadStopsNo further automated reminders on that invoice
Fig 01 · INV-20841 · Tomás Herrera
Payment of 240.00 received for INV-20841. Thank you. Your next instalment is due on 14 October.
Sent 10:04 · from Flow · template Payment_Confirmed
Can I move the October one to the 20th? I get paid on the 18th.
Received 10:31 · Case created · linked to INV-20841
Yes. October's instalment is moved to the 20th and nothing further is needed from you.
Sent 10:44 · sent by Finance from the Converse view
04 · Replies and exceptions

Three replies do almost all of the work.

Every inbound message creates or updates a Case linked to the invoice, so Finance answers with the history in front of them.

ReplyWhat happensWhere it lands
"Can I move the date?" Case for the Finance queue with the invoice attached. A person changes the date, and the reminder sequence picks up the new one on its next run. Case, linked to the invoice
"I already paid" Case raised, and the reminder sequence is suppressed on that invoice until somebody closes it. Chasing a customer who has paid costs more than a late payment. Case, Last_Reminder_Stage__c held
Payment question Case for the Finance queue. Nothing automatic, because a wrong automatic answer about money is worse than a slow one. Case
STOP Opt-out on the Contact, immediately and for every invoice. Statutory notices continue by post or email, which is the point of keeping the two separate. Contact.SMS_Opt_Out__c
05 · Guardrails

Four, and one of them is about tone.

ConsentPermission to message is checked before every send. A payment relationship is not consent to text, and treating it as one is the mistake that draws a complaint.
Opt-outHonoured immediately, and it stops future reminders as well as the current sequence. The invoice keeps its record of what was already sent.
Odd hoursNo reminder outside your business window in the recipient's own time zone. A payment reminder at 23:00 reads as a threat.
LoggedTemplate, time sent, delivery status and the related invoice, on every message. This is the guardrail that turns an audit into a report.
06 · Reporting afterwards

The message history is on the invoice, so the report writes itself.

Group by stage and you can see which reminder actually moves money, and stop sending the ones that do not.

Payment plans · reminder stagesInvoices
StageSentPaid within 48hReplies
Due minus 31,86038%44
Due minus 11,14831%61
Due plus 179227%138
Escalated20414%n/a
PAID WITHIN 48HInvoices moving to Received within two days of that stage. It is the only column that argues for keeping a stage.
REPLIESInbound messages per stage. The day-after spike is people asking to reschedule, which is a good outcome and not a failure.
ESCALATEDInvoices that reached the collections queue. A falling number here is the reminders working.
07 · Implementation note

Where ValueText fits.

ValueText is the send action and the inbound handler. It adds the Send Message invocable action to Flow Builder, writes every message and its delivery status back to the related record, and routes inbound replies into a Case with the thread attached. Templates, keyword rules and the org-level send window live in ValueText Setup. The two flows, the stage fields and the report are yours, built with standard tools, and they keep working if you change the number or the carrier.

Professional edition or above · Works with any payment or invoice object, standard or custom · 1 SMS segment per notice at the published per-country rate
AppExchange review

“ValueText provided everything my client was looking for, and more besides…”

Matt Wilson Matt WilsonAppExchange review
This page sits underSMS for SalesforceThe channel page: how sending, receiving and billing work for SMS.
In the docs
01 Schedule Messages via Process Builder in SalesforceScheduled sends and the fields that drive them → 02 Configure Message-to-Activity LoggingGetting every message onto the related record for an audit → 03 Opt-Out and Opt-In Management in SalesforceWhere the opt-out lives and what honours it →

Run your messaging inside your CRM.

Rated 4.98 on Salesforce AppExchange
Talk to us Request a sandbox
ValueText ValueText
Salesforce Use case · Finance · Invoice

Confirm the payment, then remind gently, and be able to prove both.

One flow fires on payment received. A scheduled flow handles what is due and what is late. Both write back to the invoice, so Finance and Support read the same history instead of chasing it across tools.

ObjectInvoice, or your payment record
Fires onPayment received, and a daily due-date sweep
Reply landsCase, linked to the invoice
ChannelSMS or WhatsApp, by contact preference
01 · What quietly breaks

The risk is not forgetting to send. It is not being able to prove what you sent.

Most teams get as far as sending reminders. What breaks is everything around them: the message is not linked to the invoice, so nobody can trace it later. The timing lives in a spreadsheet, so a changed due date quietly stops working.

Replies land in somebody's personal inbox instead of a tracked work item, and the follow-up is missed. Consent and opt-outs are handled differently by each person doing the sending.

Then a customer disputes a charge, and the question is what they were told and when. If the answer is in a phone, it is not an answer.

02 · The idea

Keep the process where the record is. A change in Salesforce sends the message, Salesforce decides who and what, and the message is logged back to the invoice it belongs to.

03 · The pattern

Two automations, kept separate on purpose.

A confirmation is immediate and unconditional. A reminder is scheduled and conditional. Merging them into one flow is what makes reminder logic unreadable six months later.

01

Confirmation, the moment money lands

Fires when the payment is marked received. It finds the contact linked to that payment, sends a short confirmation with the amount and the next due date, and writes the message and its delivery status back to the record.

This is the one that pays for itself in avoided calls, and it is also the one that settles a dispute later.

In Salesforce Flow typeRecord-triggered, payment record, after saveEntryStatus → ReceivedTemplatePayment_ConfirmedWrites backMessage Bucket on the invoice, delivery status
02

Reminders, on a schedule and in a sequence

A daily scheduled flow checks what is due and what is overdue, and sends at most one message per invoice per stage: a friendly note a few days before, a short nudge the day before, and a polite line the day after if it is still unpaid, inviting a reply to reschedule.

The stage stamp is what keeps it gentle. Without it, a changed due date re-triggers the sequence and the customer gets the same reminder four times, which is how a payments channel gets muted.

In Salesforce Flow typeSchedule-triggered, dailyStagesDue minus 3, due minus 1, due plus 1StampLast_Reminder_Stage__c, Last_Reminder_Sent__cSuppressSkip if a reminder was sent within the cooling period
03

Escalate to a person, only when it is needed

Past the last stage, the flow stops messaging and creates a Case for the collections queue with the thread attached. Nothing after that is automatic, because the conversation after a missed payment is not one to automate.

In Salesforce TriggerOverdue past the final stageCreatesCase, queue = Collections, linked to the invoiceAttachesThe full message threadStopsNo further automated reminders on that invoice
Fig 01 · INV-20841 · Tomás Herrera
Payment of 240.00 received for INV-20841. Thank you. Your next instalment is due on 14 October.
Sent 10:04 · from Flow · template Payment_Confirmed
Can I move the October one to the 20th? I get paid on the 18th.
Received 10:31 · Case created · linked to INV-20841
Yes. October's instalment is moved to the 20th and nothing further is needed from you.
Sent 10:44 · sent by Finance from the Converse view
04 · Replies and exceptions

Three replies do almost all of the work.

Every inbound message creates or updates a Case linked to the invoice, so Finance answers with the history in front of them.

ReplyWhat happensWhere it lands
"Can I move the date?" Case for the Finance queue with the invoice attached. A person changes the date, and the reminder sequence picks up the new one on its next run. Case, linked to the invoice
"I already paid" Case raised, and the reminder sequence is suppressed on that invoice until somebody closes it. Chasing a customer who has paid costs more than a late payment. Case, Last_Reminder_Stage__c held
Payment question Case for the Finance queue. Nothing automatic, because a wrong automatic answer about money is worse than a slow one. Case
STOP Opt-out on the Contact, immediately and for every invoice. Statutory notices continue by post or email, which is the point of keeping the two separate. Contact.SMS_Opt_Out__c
05 · Guardrails

Four, and one of them is about tone.

ConsentPermission to message is checked before every send. A payment relationship is not consent to text, and treating it as one is the mistake that draws a complaint.
Opt-outHonoured immediately, and it stops future reminders as well as the current sequence. The invoice keeps its record of what was already sent.
Odd hoursNo reminder outside your business window in the recipient's own time zone. A payment reminder at 23:00 reads as a threat.
LoggedTemplate, time sent, delivery status and the related invoice, on every message. This is the guardrail that turns an audit into a report.
06 · Reporting afterwards

The message history is on the invoice, so the report writes itself.

Group by stage and you can see which reminder actually moves money, and stop sending the ones that do not.

Payment plans · reminder stagesInvoices
StageSentPaid within 48hReplies
Due minus 31,86038%44
Due minus 11,14831%61
Due plus 179227%138
Escalated20414%n/a
PAID WITHIN 48HInvoices moving to Received within two days of that stage. It is the only column that argues for keeping a stage.
REPLIESInbound messages per stage. The day-after spike is people asking to reschedule, which is a good outcome and not a failure.
ESCALATEDInvoices that reached the collections queue. A falling number here is the reminders working.
07 · Implementation note

Where ValueText fits.

ValueText is the send action and the inbound handler. It adds the Send Message invocable action to Flow Builder, writes every message and its delivery status back to the related record, and routes inbound replies into a Case with the thread attached. Templates, keyword rules and the org-level send window live in ValueText Setup. The two flows, the stage fields and the report are yours, built with standard tools, and they keep working if you change the number or the carrier.

Professional edition or above · Works with any payment or invoice object, standard or custom · 1 SMS segment per notice at the published per-country rate
AppExchange review

“ValueText provided everything my client was looking for, and more besides…”

Matt Wilson Matt WilsonAppExchange review
This page sits underSMS for SalesforceThe channel page: how sending, receiving and billing work for SMS.
In the docs
01 Schedule Messages via Process Builder in SalesforceScheduled sends and the fields that drive them → 02 Configure Message-to-Activity LoggingGetting every message onto the related record for an audit → 03 Opt-Out and Opt-In Management in SalesforceWhere the opt-out lives and what honours it →

Run your messaging inside your CRM.

Rated 4.98 on Salesforce AppExchange
Talk to us Request a sandbox
ValueText ValueText
Salesforce Use case · Finance · Invoice

Confirm the payment, then remind gently, and be able to prove both.

One flow fires on payment received. A scheduled flow handles what is due and what is late. Both write back to the invoice, so Finance and Support read the same history instead of chasing it across tools.

ObjectInvoice, or your payment record
Fires onPayment received, and a daily due-date sweep
Reply landsCase, linked to the invoice
ChannelSMS or WhatsApp, by contact preference
01 · What quietly breaks

The risk is not forgetting to send. It is not being able to prove what you sent.

Most teams get as far as sending reminders. What breaks is everything around them: the message is not linked to the invoice, so nobody can trace it later. The timing lives in a spreadsheet, so a changed due date quietly stops working.

Replies land in somebody's personal inbox instead of a tracked work item, and the follow-up is missed. Consent and opt-outs are handled differently by each person doing the sending.

Then a customer disputes a charge, and the question is what they were told and when. If the answer is in a phone, it is not an answer.

02 · The idea

Keep the process where the record is. A change in Salesforce sends the message, Salesforce decides who and what, and the message is logged back to the invoice it belongs to.

03 · The pattern

Two automations, kept separate on purpose.

A confirmation is immediate and unconditional. A reminder is scheduled and conditional. Merging them into one flow is what makes reminder logic unreadable six months later.

01

Confirmation, the moment money lands

Fires when the payment is marked received. It finds the contact linked to that payment, sends a short confirmation with the amount and the next due date, and writes the message and its delivery status back to the record.

This is the one that pays for itself in avoided calls, and it is also the one that settles a dispute later.

In Salesforce Flow typeRecord-triggered, payment record, after saveEntryStatus → ReceivedTemplatePayment_ConfirmedWrites backMessage Bucket on the invoice, delivery status
02

Reminders, on a schedule and in a sequence

A daily scheduled flow checks what is due and what is overdue, and sends at most one message per invoice per stage: a friendly note a few days before, a short nudge the day before, and a polite line the day after if it is still unpaid, inviting a reply to reschedule.

The stage stamp is what keeps it gentle. Without it, a changed due date re-triggers the sequence and the customer gets the same reminder four times, which is how a payments channel gets muted.

In Salesforce Flow typeSchedule-triggered, dailyStagesDue minus 3, due minus 1, due plus 1StampLast_Reminder_Stage__c, Last_Reminder_Sent__cSuppressSkip if a reminder was sent within the cooling period
03

Escalate to a person, only when it is needed

Past the last stage, the flow stops messaging and creates a Case for the collections queue with the thread attached. Nothing after that is automatic, because the conversation after a missed payment is not one to automate.

In Salesforce TriggerOverdue past the final stageCreatesCase, queue = Collections, linked to the invoiceAttachesThe full message threadStopsNo further automated reminders on that invoice
Fig 01 · INV-20841 · Tomás Herrera
Payment of 240.00 received for INV-20841. Thank you. Your next instalment is due on 14 October.
Sent 10:04 · from Flow · template Payment_Confirmed
Can I move the October one to the 20th? I get paid on the 18th.
Received 10:31 · Case created · linked to INV-20841
Yes. October's instalment is moved to the 20th and nothing further is needed from you.
Sent 10:44 · sent by Finance from the Converse view
04 · Replies and exceptions

Three replies do almost all of the work.

Every inbound message creates or updates a Case linked to the invoice, so Finance answers with the history in front of them.

ReplyWhat happensWhere it lands
"Can I move the date?" Case for the Finance queue with the invoice attached. A person changes the date, and the reminder sequence picks up the new one on its next run. Case, linked to the invoice
"I already paid" Case raised, and the reminder sequence is suppressed on that invoice until somebody closes it. Chasing a customer who has paid costs more than a late payment. Case, Last_Reminder_Stage__c held
Payment question Case for the Finance queue. Nothing automatic, because a wrong automatic answer about money is worse than a slow one. Case
STOP Opt-out on the Contact, immediately and for every invoice. Statutory notices continue by post or email, which is the point of keeping the two separate. Contact.SMS_Opt_Out__c
05 · Guardrails

Four, and one of them is about tone.

ConsentPermission to message is checked before every send. A payment relationship is not consent to text, and treating it as one is the mistake that draws a complaint.
Opt-outHonoured immediately, and it stops future reminders as well as the current sequence. The invoice keeps its record of what was already sent.
Odd hoursNo reminder outside your business window in the recipient's own time zone. A payment reminder at 23:00 reads as a threat.
LoggedTemplate, time sent, delivery status and the related invoice, on every message. This is the guardrail that turns an audit into a report.
06 · Reporting afterwards

The message history is on the invoice, so the report writes itself.

Group by stage and you can see which reminder actually moves money, and stop sending the ones that do not.

Payment plans · reminder stagesInvoices
StageSentPaid within 48hReplies
Due minus 31,86038%44
Due minus 11,14831%61
Due plus 179227%138
Escalated20414%n/a
PAID WITHIN 48HInvoices moving to Received within two days of that stage. It is the only column that argues for keeping a stage.
REPLIESInbound messages per stage. The day-after spike is people asking to reschedule, which is a good outcome and not a failure.
ESCALATEDInvoices that reached the collections queue. A falling number here is the reminders working.
07 · Implementation note

Where ValueText fits.

ValueText is the send action and the inbound handler. It adds the Send Message invocable action to Flow Builder, writes every message and its delivery status back to the related record, and routes inbound replies into a Case with the thread attached. Templates, keyword rules and the org-level send window live in ValueText Setup. The two flows, the stage fields and the report are yours, built with standard tools, and they keep working if you change the number or the carrier.

Professional edition or above · Works with any payment or invoice object, standard or custom · 1 SMS segment per notice at the published per-country rate
AppExchange review

“ValueText provided everything my client was looking for, and more besides…”

Matt Wilson Matt WilsonAppExchange review
This page sits underSMS for SalesforceThe channel page: how sending, receiving and billing work for SMS.
In the docs
01 Schedule Messages via Process Builder in SalesforceScheduled sends and the fields that drive them → 02 Configure Message-to-Activity LoggingGetting every message onto the related record for an audit → 03 Opt-Out and Opt-In Management in SalesforceWhere the opt-out lives and what honours it →

Run your messaging inside your CRM.

Rated 4.98 on Salesforce AppExchange
Talk to us Request a sandbox
ValueText ValueText
Salesforce Use case · Finance · Invoice

Confirm the payment, then remind gently, and be able to prove both.

One flow fires on payment received. A scheduled flow handles what is due and what is late. Both write back to the invoice, so Finance and Support read the same history instead of chasing it across tools.

ObjectInvoice, or your payment record
Fires onPayment received, and a daily due-date sweep
Reply landsCase, linked to the invoice
ChannelSMS or WhatsApp, by contact preference
01 · What quietly breaks

The risk is not forgetting to send. It is not being able to prove what you sent.

Most teams get as far as sending reminders. What breaks is everything around them: the message is not linked to the invoice, so nobody can trace it later. The timing lives in a spreadsheet, so a changed due date quietly stops working.

Replies land in somebody's personal inbox instead of a tracked work item, and the follow-up is missed. Consent and opt-outs are handled differently by each person doing the sending.

Then a customer disputes a charge, and the question is what they were told and when. If the answer is in a phone, it is not an answer.

02 · The idea

Keep the process where the record is. A change in Salesforce sends the message, Salesforce decides who and what, and the message is logged back to the invoice it belongs to.

03 · The pattern

Two automations, kept separate on purpose.

A confirmation is immediate and unconditional. A reminder is scheduled and conditional. Merging them into one flow is what makes reminder logic unreadable six months later.

01

Confirmation, the moment money lands

Fires when the payment is marked received. It finds the contact linked to that payment, sends a short confirmation with the amount and the next due date, and writes the message and its delivery status back to the record.

This is the one that pays for itself in avoided calls, and it is also the one that settles a dispute later.

In Salesforce Flow typeRecord-triggered, payment record, after saveEntryStatus → ReceivedTemplatePayment_ConfirmedWrites backMessage Bucket on the invoice, delivery status
02

Reminders, on a schedule and in a sequence

A daily scheduled flow checks what is due and what is overdue, and sends at most one message per invoice per stage: a friendly note a few days before, a short nudge the day before, and a polite line the day after if it is still unpaid, inviting a reply to reschedule.

The stage stamp is what keeps it gentle. Without it, a changed due date re-triggers the sequence and the customer gets the same reminder four times, which is how a payments channel gets muted.

In Salesforce Flow typeSchedule-triggered, dailyStagesDue minus 3, due minus 1, due plus 1StampLast_Reminder_Stage__c, Last_Reminder_Sent__cSuppressSkip if a reminder was sent within the cooling period
03

Escalate to a person, only when it is needed

Past the last stage, the flow stops messaging and creates a Case for the collections queue with the thread attached. Nothing after that is automatic, because the conversation after a missed payment is not one to automate.

In Salesforce TriggerOverdue past the final stageCreatesCase, queue = Collections, linked to the invoiceAttachesThe full message threadStopsNo further automated reminders on that invoice
Fig 01 · INV-20841 · Tomás Herrera
Payment of 240.00 received for INV-20841. Thank you. Your next instalment is due on 14 October.
Sent 10:04 · from Flow · template Payment_Confirmed
Can I move the October one to the 20th? I get paid on the 18th.
Received 10:31 · Case created · linked to INV-20841
Yes. October's instalment is moved to the 20th and nothing further is needed from you.
Sent 10:44 · sent by Finance from the Converse view
04 · Replies and exceptions

Three replies do almost all of the work.

Every inbound message creates or updates a Case linked to the invoice, so Finance answers with the history in front of them.

ReplyWhat happensWhere it lands
"Can I move the date?" Case for the Finance queue with the invoice attached. A person changes the date, and the reminder sequence picks up the new one on its next run. Case, linked to the invoice
"I already paid" Case raised, and the reminder sequence is suppressed on that invoice until somebody closes it. Chasing a customer who has paid costs more than a late payment. Case, Last_Reminder_Stage__c held
Payment question Case for the Finance queue. Nothing automatic, because a wrong automatic answer about money is worse than a slow one. Case
STOP Opt-out on the Contact, immediately and for every invoice. Statutory notices continue by post or email, which is the point of keeping the two separate. Contact.SMS_Opt_Out__c
05 · Guardrails

Four, and one of them is about tone.

ConsentPermission to message is checked before every send. A payment relationship is not consent to text, and treating it as one is the mistake that draws a complaint.
Opt-outHonoured immediately, and it stops future reminders as well as the current sequence. The invoice keeps its record of what was already sent.
Odd hoursNo reminder outside your business window in the recipient's own time zone. A payment reminder at 23:00 reads as a threat.
LoggedTemplate, time sent, delivery status and the related invoice, on every message. This is the guardrail that turns an audit into a report.
06 · Reporting afterwards

The message history is on the invoice, so the report writes itself.

Group by stage and you can see which reminder actually moves money, and stop sending the ones that do not.

Payment plans · reminder stagesInvoices
StageSentPaid within 48hReplies
Due minus 31,86038%44
Due minus 11,14831%61
Due plus 179227%138
Escalated20414%n/a
PAID WITHIN 48HInvoices moving to Received within two days of that stage. It is the only column that argues for keeping a stage.
REPLIESInbound messages per stage. The day-after spike is people asking to reschedule, which is a good outcome and not a failure.
ESCALATEDInvoices that reached the collections queue. A falling number here is the reminders working.
07 · Implementation note

Where ValueText fits.

ValueText is the send action and the inbound handler. It adds the Send Message invocable action to Flow Builder, writes every message and its delivery status back to the related record, and routes inbound replies into a Case with the thread attached. Templates, keyword rules and the org-level send window live in ValueText Setup. The two flows, the stage fields and the report are yours, built with standard tools, and they keep working if you change the number or the carrier.

Professional edition or above · Works with any payment or invoice object, standard or custom · 1 SMS segment per notice at the published per-country rate
AppExchange review

“ValueText provided everything my client was looking for, and more besides…”

Matt Wilson Matt WilsonAppExchange review
This page sits underSMS for SalesforceThe channel page: how sending, receiving and billing work for SMS.
In the docs
01 Schedule Messages via Process Builder in SalesforceScheduled sends and the fields that drive them → 02 Configure Message-to-Activity LoggingGetting every message onto the related record for an audit → 03 Opt-Out and Opt-In Management in SalesforceWhere the opt-out lives and what honours it →

Run your messaging inside your CRM.

Rated 4.98 on Salesforce AppExchange
Talk to us Request a sandbox