This article covers everything that can go wrong once your batch is committed and you are ready to tell residents about it: on the Send card, described in Sending the messages to residents . It is...
Last updated
This article covers everything that can go wrong once your batch is committed and you are ready to tell residents about it: on the Send card, described in Sending the messages to residents. It is for staff, property managers and board members who pressed Send, tried to schedule a send, tried to remind someone, or opened the Send card and found something was not quite right.
Batches where residents are sent an agreement to sign, and fees only batches, wait on the Send card until you press Send now or Send on a date. The messages in this article mostly belong to those two kinds of batch.
A batch where staff declared that they already hold signed paper agreements is different. It has no communication date, and its setup emails do not wait for you. Each resident gets one setup email automatically when the import commits, as long as at least one declared row was billed. Once those emails have gone out, the Send card shows the batch as sent, and a sent batch never sends again. The communication date and ten day messages below do not apply to a declared batch.
These are the messages you see before anything actually goes out. Each one names the exact thing stopping the send.
What it means. The batch has not been committed yet, so there is nothing ready to send.
Why it happened. You reached the Send card, or pressed a send control, on a batch that is still in the wizard rather than committed.
What to do. Finish the wizard and commit the batch first. See After you commit for what happens at that point.
What it means. The batch has no fee start date recorded, so URBI cannot work out whether it is allowed to send anything yet.
Why it happened. The fee start date field on Launch settings was left empty, or was cleared after the batch was committed.
What to do. Open Launch settings and set the fee start date, then try sending again.
What it means. The date you have chosen to tell residents about this fee has already passed. This applies to batches where residents sign an agreement and to fees only batches. A declared batch has no communication date.
Why it happened. The communication date on the batch is set to a day before today, most often because the batch sat for a while before you came back to send it.
What to do. Open Launch settings and choose today or a later date for the communication date.
What it means. For a batch with bank debit agreements for residents to sign, URBI requires at least ten days between the day residents are told about the fee and the day that fee actually starts. Your two dates are closer together than that.
A fees only batch has no bank debit rows, so it has no ten day rule. Its fee can start within ten days of the communication date. Launch settings says so: "No bank debit rows in this batch, so there is no 10-day rule. A (fee) can start within 10 days of the communication date." The communication date still cannot be earlier than today. A declared batch has no communication date at all.
Why it happened. The communication date and the fee start date on this batch do not leave the full ten day gap.
What to do. Open Launch settings and move one of the two dates so that at least ten days sit between them.
What it means. This is for a batch where residents are sent bank debit agreements to sign. The fee start date itself is now so close that there is no day left on which a bank debit message could legally go out ten days ahead of it. This is a stronger version of the message above: moving the communication date alone will not fix it, because there is no valid date left to move it to.
Why it happened. Time has passed since the batch was committed and the fee start date is now fewer than ten days away.
What to do. Open Launch settings and move the fee start date further out. You will see this same message there, in a red block under the communication date, and again here on the Send card, next to the send controls, with a link straight to Launch settings.
The Send card's held back notice, with its link to the step where you fix the date.
What it means. The same ten day rule as above, for a batch where residents sign bank debit agreements, caught at the exact moment you pressed Send rather than while the card was simply sitting open.
Why it happened. The fee start date moved into the closed window between the page loading and you pressing Send.
What to do. Open Launch settings and move the fee start date further out, then come back and send again.
What it means. Every message in this batch is either excluded, held back, or already sent, so pressing Send has nothing left to do.
Why it happened. This usually means every remaining message is waiting on a held back reason. Read the amber sticky lines on the Send card, described below under Messages are being held back.
What to do. Fix whichever held back reasons apply, then try sending again.
What it means. The request to start sending failed before anything was sent. Nothing went to residents.
Why it happened. The send request itself did not complete on the server.
What to do. Try pressing Send again. If it keeps happening, contact your URBI administrator.
These messages mean the Send card itself could not show you your batch or its recipients. Nothing has been sent or lost, the page simply could not read what it needed.
What it means. The Send card could not read the list of prepared messages for this batch.
Why it happened. A read the card needs failed on the server.
What to do. Reload the page.
What it means. The Send card could not find any committed batch to show for this property.
Why it happened. The read that looks up your most recent committed batch failed.
What to do. Reload the page.
What it means. The Send card could not put together the numbers it needs to show you: how many messages, how many rows, and their state.
Why it happened. One of the reads behind the send summary failed. The message you see may include more detail after a colon.
What to do. Reload the page.
What it means. The Send card could not read basic information about your batch or your property.
Why it happened. A read failed on the server.
What to do. Reload the page. If it keeps happening, contact your URBI administrator.
What it means. A send for this batch is already in progress right now.
Why it happened. You, or someone else with access to this property, already pressed Send, and it has not finished yet.
What to do. Wait for it to finish. Pressing Send again will not start a second, separate send.
After a send finishes, the Send card tells you exactly how many messages went out and how many did not.
What it means. The send finished, but not every message could be delivered. The ones that were sent are done, the ones that failed are listed for you underneath.
Why it happened. At least one message failed for a reason specific to that person. See the list of reasons below.
What to do. Read the "Failed to send" list and the reason next to each name.
What it means. The send stopped without sending or failing a single message. It is stuck in the middle, not finished and not failed.
Why it happened. The run that carries out the send did not reach an end state.
What to do. Wait. URBI checks for stuck sends once an hour and will recover it automatically. If it is still stuck after that, try sending again.
What it means. URBI genuinely does not know whether these particular messages arrived, but it will not resend them, because they may already have landed and a second copy could confuse the recipient.
Why it happened. The email provider never confirmed the outcome for these messages one way or the other.
What to do. Contact those people directly to check whether they received it, rather than assuming either way.
Under the heading "Failed to send (N)", every message that could not be delivered is listed by name with a plain reason next to it. Go through each name and match its reason to one of the entries below.
The Failed to send list, with two example rows and their reasons.
| Sarah Chen, Unit 304 | Bounced |
| David Okafor, Unit 512 | Already signed |
Here is what each reason means for that one person, and what you can do about it.
What it means. The email provider rejected this person's address outright. The message never reached an inbox.
Why it happened. The email address on file for this person is wrong, closed, or does not accept mail.
What to do.
What it means. URBI sent the message, but never received word back that it actually arrived.
Why it happened. The email provider did not confirm a final outcome for this address.
What to do. Contact this person directly to check whether they received it. Do not assume it landed, and do not assume it did not.
What it means. This message is supposed to point a person to a bank debit agreement, but no agreement exists for this row on this property.
Why it happened. The bank debit row behind this message has not been committed, or its agreement never landed on this property.
What to do. Commit the bank debit row first, then send again.
What it means. By the time this message was actually sent, the ten day rule had closed, so it could not go out after all.
Why it happened. The fee start date moved closer, or enough time passed, since the batch was prepared.
What to do. Move the fee start date later on the Launch settings step, then send again.
What it means. This message could not be sent because the batch has no fee start date at all.
Why it happened. The fee start date field on Launch settings is empty.
What to do. Set a fee start date on Launch settings, then send again.
What it means. The property is no longer able to accept bank debit payments, so this message could not go out.
Why it happened. The property lost its bank debit readiness between commit and send. This can be the property's country, its connected collection account, or the wording of its agreement template.
What to do. Fix whatever is missing from the property's bank debit setup, then send again. If you are not sure what changed, contact your URBI administrator.
What it means. This message was a set-up invitation, but the toggle that allows those invitations was switched off before it could go out.
Why it happened. Someone turned off "Send set-up invitations" on Launch settings after the batch was committed.
What to do. If you still want this invitation sent, turn "Send set-up invitations" back on in Launch settings, then send again.
What it means. This message needed a fresh link for the person to sign their agreement, and URBI could not create one.
Why it happened. The step that mints a new signing link failed for this agreement.
What to do. Try sending again.
What it means. This person had already signed every agreement this message would have covered, so there was nothing left to ask them to do.
Why it happened. The agreement was signed between the batch being prepared and the message being sent.
What to do. Nothing. This is fine.
What it means. This message failed for a reason URBI did not record, or one it does not recognise.
Why it happened. No specific cause is available for this one.
What to do. Contact this person directly.
"Held back" is different from "failed". A held back message has not been attempted at all. It is fully prepared and waiting, but URBI will not release it yet because of a specific, named problem. Fixing the problem lets it go out on the next send; nothing needs to be recreated.
The most common held back notice you will see covers the whole batch at once:
"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 is the same ten day rule described above under The send would not start. It applies only to a batch where residents are sent bank debit agreements to sign. A fees only batch has no ten day rule, and a declared batch has no communication date and holds nothing back for this reason. The rule affects only the two kinds of message tied to a bank debit agreement (sign requests and acknowledgement notices), because those two are the only ones it governs. Set-up invitations and amount change notices are never held back for this reason and go out on schedule regardless.
The one action that releases anything held back for this reason is the same in every case: open Launch settings and move the fee start date so that the required ten day gap exists again, or, if the communication date is the problem, move it back inside the window.
Beyond that one shared reason, other held back lines name one exact person and one exact problem, in the form "Held back: (what). (reason)." for example "Held back: 2 sign requests. No email on file." The two you are most likely to see are:
What it means. URBI has nobody to send this message to. There is no resident account for this person, and no invitation email is currently active for them either.
Why it happened. The person on this row was never invited, or their earlier invitation has expired without them acting on it.
What to do. Add an email address for this person, then start a new batch to message them. This particular held message cannot be released in place.
What it means. This person was newly invited during the wizard rather than chosen from someone already on the unit, so their account has not been set up yet.
Why it happened. When you send the batch, URBI tries to create their account, any bank debit enrolment, and any held invoice automatically, in that order. This message means that step has not finished yet.
What to do. Wait, then try the send again. Their bank details are never thrown away while this is pending, so nothing is at risk by waiting.
A scheduled send shows "Scheduled for (date) at 9:00 AM building time" on the Send card. Two extra lines can appear alongside that date:
If you decide you do not want the scheduled send to happen, press Cancel schedule. You will see:
"Cancel the scheduled send?" "Nothing has been sent yet."
with Cancel schedule and Keep schedule to finish your choice. Confirming means nothing from this batch goes out until you schedule or send it again.
The Remind unsigned button emails everyone in the batch who has not yet signed their agreement.
What it means. There is nobody left for a reminder to reach right now, either because everyone due one already got one recently, or because there is genuinely nobody unsigned.
Why it happened. Either every unsigned person was reminded within the last three days, so URBI will not repeat itself yet, or every agreement in the batch is already signed.
What to do. Nothing. If people were recently reminded, wait three days and the button will be available again for anyone still unsigned.
What it means. The request to send reminders did not complete. No reminder emails went out.
Why it happened. The reminder route or the task behind it failed. You may see more detail after a colon.
What to do. Try pressing Remind unsigned again.
What it means. URBI could not read who has already been sent a sign request, so it could not work out who still needs reminding.
Why it happened. A read behind the remind action failed.
What to do. Try again.
Sending a batch is a snapshot of what was committed at that exact moment. Two related messages can appear afterward.
What it means. Some rows in this batch were still sitting uncommitted when you sent the others. Their messages were not part of this send.
Why it happened. Not every row in the batch had finished the wizard and been committed before Send was pressed.
What to do. Commit those remaining rows, then start a new batch for their own messages. They are not automatically added to a batch that has already sent.
What it means. New rows were committed to this batch after its messages already went out.
Why it happened. A batch that has already sent its messages cannot send a second, different set later.
What to do. Start a new batch to message these rows. They need a batch of their own.
Once a message has gone out, that is final. The Send card states this plainly once a batch has been sent: "Sent messages cannot be recalled." There is no undo, no unsend, and no way to edit a message after it has been delivered. If something needs correcting after the fact, the only option is to contact that person directly.
The other side of this is a guarantee, not a risk: a person who has already been sent a particular message from a particular row is never sent that same message again. If you start a new batch, nobody receives a duplicate of a message they were already sent.