Sending the messages to residents

This article covers the Send card, the last stage of the bulk upload, where the messages prepared by your committed batch actually go out to residents. It is for staff, property managers and board members who have already committed a batch and are ready to tell residents about it, or who need to understand a failed or held back message.

What commit sends, and what waits for you

This is the single most important thing to understand about this stage, and it depends on how the batch collects bank debit permission.

Most batches: committing does not email anyone. If each person is sent an agreement to sign, or the batch has only fees, or only bank details, creating the leases, billing accounts and bank debit agreements at commit does not send a single email. Every message the batch prepares waits for you, untouched, until you choose to send it. This is deliberate. It gives you a last chance to check the dates, the recipient counts and the amounts one more time, with nothing at stake yet, before a resident's inbox is involved. You can commit a batch on a Monday and not send its messages until Thursday, or never, if you decide not to.

Paper agreements: the setup emails go at commit. If you chose "I already hold signed agreements (staff declaration)", each resident gets one setup email automatically when the import commits, as long as at least one row was billed. The first bill is created at commit too, but no invoice email is sent for it. You do not press Send for these emails. The Send card then shows them as sent, and a sent batch never sends again.

Where the Send card lives

The Send card, titled "Fee and bank debit batch", sits on the Bulk Actions tab, below the two upload entry cards, whenever the wizard itself is closed. It always shows your property's most recently committed batch. That means you can close the drawer the moment you finish committing, come back the next day, and the same batch and the same send controls are exactly where you left them.

The four kinds of message

A committed batch can prepare up to four different kinds of message, and the Send card shows one count tile for each:

1. Sign requests. Sent to each bank debit row where the batch's consent path is "Send each person the agreement to sign". Each person is asked to review their bank details and sign.
2. Acknowledgement notices. Used for each bank debit row where the batch's consent path is the staff declaration. These are the setup emails: they tell the payer that their bank details are set up and that no action is needed from them. They go out automatically at commit, so on the Send card this tile shows them as sent. You do not send them.
3. Set-up invitations. Sent to anyone in the batch with no bank debit row at all, when the "Send set-up invitations" toggle is on. These invite the person to set up their own automatic payment in the resident portal.
4. Amount change notices. Sent to anyone whose existing fee changed amount because you chose "Update" on a collision row during Review. If every one of a person's updates kept the same amount, no notice is needed and none is prepared for them.

The four count tiles on the Send card, one for each kind of message. This picture shows every tile filled to name them all. In a real batch you see sign requests or acknowledgement notices, not both, because the consent choice is made once for the whole batch.

Reading the recipient lists

Press "View recipients" under any tile to see who is on that list. To protect privacy, email addresses are shown masked, not in full. If a person has neither a name nor an email address that can be shown, the row reads "Unnamed recipient", which is worth fixing before you send.

For bank debit rows, each person's row also shows their projected or confirmed first debit, in one of two forms:

• A confirmed date: "First debit (date)". This means the agreement is already signed or declared, so the date is real.
• An estimated date: "First debit (date) if signed by (date) (estimate)". This means the person has not signed yet, so the date shown depends on when they actually sign. It will become a confirmed date once they do.

Send now versus scheduling

Above the send controls, "When should these go out?" offers two modes: Send now and Send on a date.

Sending immediately. Choosing Send now opens a confirmation window before anything actually goes:

"Send now?" "Send (N) sign requests, (N) notices, (N) invitations and (N) amount change notices now?"

Confirming starts the send right away; the button reads "Sending..." while it works.

Scheduling for later. Choosing a date and pressing "Schedule send" books the send instead of sending it immediately. Once booked, the card shows:

"Scheduled for (date) at 9:00 AM building time"

Three controls sit alongside a scheduled send:

• Reschedule lets you pick a different date and time before it goes out.
• Send now instead sends it immediately rather than waiting for the scheduled time.
• Cancel schedule opens its own confirmation, "Cancel the scheduled send?", "Nothing has been sent yet.", with Cancel schedule and Keep schedule to finish the choice.

A scheduled send, with the three controls to change your mind.

Remember from the previous article that a scheduled send is cancelled automatically if you go back and change any launch setting, with the message "The scheduled send was cancelled because launch settings changed." See Choosing your dates and launch settings for the full ten day rule, which differs by kind of batch, that governs when bank debit sign requests are even allowed to go out.

Reminders

Once sign requests are out, a Remind unsigned ((N)) button appears. Pressing it opens a confirmation:

"Remind unsigned people?" "This emails everyone in this batch who has not signed. Anyone reminded in the last 3 days is skipped. Expired links are replaced with new ones valid for 14 days."

In plain terms: reminders will not spam someone you already nudged in the last three days, and if the original link in their email has expired, the reminder carries a brand new link, valid for another 14 days from when the reminder goes out.

The failed to send list

After a send, any message that could not be delivered appears under "Failed to send ((N))" with a plain reason. Here is what each one means and what to do about it:

• "Bounced." The email provider rejected the address outright. Correct the person's email address on their record, then start a new batch to message them; a fixed address on this same batch cannot be retried directly.
• "Delivery could not be confirmed." The message was sent, but URBI never received confirmation that it arrived. Contact that person directly rather than assuming it landed.
• "The bank debit agreement has not been created yet." The message needs an agreement that does not exist on this property. Commit the bank debit row first, then send again.
• "The fee start date is less than 10 days away." The batch fell inside the ten day window after the message was already prepared. Move the fee start date later, on the Launch settings step. Only a batch where each person signs has this rule. A fees only batch has no ten day rule.
• "No fee start date is set." The batch has no fee start date at all. Set one on Launch settings.
• "Bank debit is not set up for this property yet." The property lost its bank debit readiness between commit and send. Fix readiness (country, collection account, or agreement wording) and try again.
• "Bank debit setup invitations were turned off before release." The "Send set-up invitations" toggle was switched off after the batch was committed. Turn it back on in Launch settings if you still want those invitations sent.
• "The signing link could not be renewed." URBI could not mint a fresh signing link for that agreement. Try sending again.
• "Already signed." Every agreement this message would have covered is already signed. Nothing to do here.
• "Could not be sent." No specific reason was recorded. Contact that person directly.

Held back messages

"Held back" means a message is fully prepared and waiting, but URBI will not release it yet because of a specific, named problem. The most common one you will see is:

"Sign requests and acknowledgement notices are held back until the fee start date moves or the communication date is within the 10-day window. Set-up invitations and amount change notices are not affected."

This affects the messages tied to bank debit agreements that people have to sign, because those are governed by the ten day rule. A batch with paper agreements sends its setup emails at commit, so it is not held back by the ten day rule here. A fees only batch has no ten day rule. Set-up invitations and amount change notices are never held back for this reason and go out normally.

Other held back reasons name the exact person and the exact problem, for example "Held back: 2 sign requests. No email on file." Two you are likely to see:

• "No email on file." The person has no account and no live invitation email to send to. Add an email address for that person, then start a new batch; this one cannot be retried in place.
• "The payer's account has not been created yet." This happens when the payer was newly invited during the wizard rather than chosen from people already on the unit. Their account, and their bank debit row, is created automatically the moment you send; if it still could not be created, wait and try the send again later. Their bank details are never thrown away while this is pending.

Bank debit rows waiting for the payments permission

Bank debit rows can be committed only by someone whose payments permission is not turned off. If the person who committed the batch does not have it, the fee rows still commit, but the bank debit rows wait. The Send card then says: " bank debit rows are waiting for someone with the payments permission." A member who does have the payments permission sees a Retry waiting bank debit rows button on the card. Pressing it retries the waiting rows.

Rows committed after the batch was sent

Sending a batch is a snapshot of what was committed at that moment. Two related situations can come up afterward:

• If some rows were still not committed when you sent, the card tells you: "(N) rows not committed yet are not included in this send." Commit them, and they will be included the next time you send something for this property.
• If new rows are committed to this same batch after it has already been sent, the card tells you: "(N) rows committed after this batch was sent. Start a new batch to message them." A batch that has already sent its messages cannot send a second, different set later; those rows need a fresh batch of their own.

Sent messages cannot be recalled, and nobody is messaged twice

Once a message goes out, that is final. The Send card states this plainly in its sent state: "Sent messages cannot be recalled." There is no undo, no unsend, and no way to edit a message after the fact, only the option to contact the person directly if something needs correcting.

The reverse guarantee also holds: a person who has already been sent a message is never sent that same message again from the same rows. If you resend or start a new batch, only genuinely new or previously failed recipients are messaged, never someone who already received it.

Related articles

• Uploading fees, leases and bank debit agreements in bulk: overview
• Choosing your dates and launch settings
• How bank debit consent is collected