Source: HighLevel workflow settings.
Key Takeaways
- Record the intended local send time before editing settings.
- Test populated and missing contact timezones, plus an account-setting change.
- Compare workflow execution with message acceptance and phone arrival.
Which timezone controls this reminder workflow?
Start with the workflow that actually produced the reminder. HighLevel’s workflow Settings tab offers Account Timezone or Contact Timezone for time-dependent steps, including waits and time windows. Workflow history identifies which timezone basis was used. HighLevel communication settings
For an agency managing multiple locations, write the location name beside the workflow name. Open the affected contact inside that location and record the timezone currently stored on the profile. Avoid diagnosing a client workspace while looking at a similarly named workflow elsewhere.
Then write down what “wrong time” means. Was the reminder received earlier than intended, was the appointment time inside the message incorrect, or was the timestamp displayed differently in the CRM? Keep these as separate findings. A timezone change should follow evidence about the scheduling problem you are trying to solve.
Use a test contact you control and a test workflow. Keep the message wording fixed while investigating timing. The GoHighLevel iMessage guide explains the Beam connection and workflow sending path, which helps you identify the action to inspect.
What should your timezone test sheet contain?
Build the sheet before running the test so the expected result cannot drift to match whatever happens. Use a separate row for every enrollment and keep expected times apart from observed times.
This is a proposed test plan, not a record of measured results:
| Test case | Setup to record | Evidence to compare |
|---|---|---|
| Populated contact timezone | Contact timezone differs from the location; workflow uses Contact Timezone | Intended local schedule, workflow history and phone arrival |
| Missing contact timezone | Test profile has no timezone; retain the same workflow setting | Account setting, expected fallback schedule and actual execution |
| Changed account setting | In an isolated test location, enroll before and after changing its timezone | Enrollment time, old and new settings, separate execution records |
| External sending action | Repeat the timing test through the actual Beam action | Webhook execution, message acceptance, send status and arrival |
Add columns for the appointment identifier, appointment date, intended reminder time, configured window, selected days, workflow version and result. For every timestamp, include the date and timezone label. Keep a UTC reference alongside local values when comparing records from different systems.
Use clear result labels: passed, failed or unresolved. Leave missing evidence unresolved. A missing phone observation should not become a timing pass just because the workflow shows a completed step.
Assign an owner to each failed row. The next person should be able to repeat the case from the sheet without reconstructing your settings from memory.
How do you test a populated and a missing contact timezone?
Run the populated case first, then change only the contact timezone condition. This makes it easier to investigate the difference without also changing the trigger, message or appointment.
- Record the intended schedule. Write the appointment’s date and timezone, the reminder’s intended local time and the reason for that timing.
- Prepare the populated profile. Select a known contact timezone that differs from the test location. Capture the relevant profile and workflow settings.
- Run the reminder. Observe the workflow history and the receiving phone. Save each timestamp with its timezone label.
- Prepare the missing-profile case. Use another controlled test record with no timezone. Keep the other test conditions equivalent and document any unavoidable differences.
- Compare the rows. Identify the first place where observed timing differs from the expectation you wrote down.
If the populated case fails, inspect the selected workflow mode and recorded profile value before guessing at a correction. If only the blank-profile case fails your intended schedule, review how your agency collects timezone information and handles incomplete records.
Define an operational response for unknown timezones. For example, require staff review before that contact enters a reminder sequence. Treat this as a workflow requirement to implement and test, not an automatic behavior promised by either platform.
What changes when you edit the account timezone?
HighLevel says an account timezone change affects new workflow entries, not contacts already running through the workflow. Test both groups. HighLevel account-change guidance
Use an isolated test location for this case. Capture its original setting and enroll a test contact before the change. Record the enrollment time, change the account setting, then create a fresh test enrollment with a distinct appointment identifier.
Keep both rows visible in the sheet. Label them “entered before change” and “entered after change.” Avoid deleting the earlier run simply because it does not match the fresh run; the comparison is the purpose of the test.
After documenting the result, restore the test location’s intended configuration. For a client correction, first inventory reminders already in progress and decide which require individual review. Do not bulk re-enroll customers merely to make their records match a new setting. Review the existing send history before scheduling a replacement reminder.
How should configured business windows be checked?
Check the window separately from the timezone. HighLevel documents a Specific Time setting with start time, end time and included days; covered communication actions outside the window wait for the next available slot. HighLevel time-window documentation
Ask the client to define the intended business window, including its timezone. Record what should happen when an appointment reminder falls outside it. A postponed reminder may no longer serve the appointment, so specify whether that case needs staff review, an earlier reminder or another tested route.
Test an action inside the window, an action outside it and an excluded day. Use the same message and controlled recipient. Inspect the point where the workflow pauses or continues, then compare that event with the expected schedule.
Keep the distinction clear: This sheet tests configured business preferences. It does not establish legal calling or texting hours.
If the sequence also includes voice follow-up, document that action’s timing separately. Agencies evaluating that part of the sequence can review RizzDial’s GoHighLevel calling integration alongside the text test, without assuming the channels share scheduling controls.
Does the external Beam action obey the same schedule?
Confirm the external action’s timing through a controlled run. Beam’s documented workflow path uses a Custom Webhook, while GoHighLevel’s regular Send SMS action uses the default SMS provider. The Beam documentation includes the workflow setup and validation procedure.
Do not treat documentation about native communication windows as proof of how your Custom Webhook executes. Ask the implementer to identify exactly where the reminder is held until its intended time and what prevents the external request from running early.
Follow the documented dry-run procedure to validate the connection first. Then use your own test phone for a permitted send through the scheduled workflow. Record:
- When the workflow reaches the external action.
- When the request is accepted and which message identifier it returns.
- When the message status changes to sent, if available.
- When the test phone receives the reminder.
Beam distinguishes queued acceptance from sending and delivery. Its iMessage API overview provides a starting point for reviewing message status and event handling. A successful request alone cannot establish arrival timing.
If the external request happens early, investigate the scheduling steps before that request. If the request occurs as intended but arrival is late, preserve the message identifier and examine the downstream status evidence. Ask whether configured sending hours or line pacing affected that message; do not assign a cause without the record.
Keep the test focused on the real path the client will use. Manually clicking send may verify the recipient and line, but it does not exercise the scheduled reminder sequence.
What should your agency verify before enabling reminders?
Require completed evidence for each test case, a named owner for unresolved timing issues and a saved copy of the intended settings. Give the client a short explanation of which timezone governs the reminder and how incomplete contact records will be handled.
Bring the timezone sheet and external-action results when discussing your setup. Text our team to try it.
What are the frequently asked questions about reminder timing?
What happens when a contact timezone is missing?
With Contact Timezone selected, HighLevel uses the account timezone when the contact profile has none. Include a blank-profile case in your test sheet.
Will changing the account timezone fix reminders already running?
HighLevel says account timezone changes apply to new workflow entries, not contacts already running through the workflow. Compare existing and fresh test enrollments.
Does a successful Beam webhook prove the reminder arrived on time?
No. A queued response confirms acceptance. Compare workflow execution, Beam message status and arrival on the test phone before marking the timing test complete.
Should every client location use the same timezone setup?
Use the same review process, but record each location's intended timezone and business window separately. Test the actual client configuration before copying its settings elsewhere.