Automations overview

Automations evaluate eligible Stays and prepare Survey communications at a configured time. The evidence chain is Stay → eligibility → Automation occurrence → Survey Invitation → Communication → Survey Response. Each record has a different meaning; an Automation does not change a Stay status.

Find and manage Automations

From the left sidebar, select Automations. Access is limited to Automations for Properties your role can view. The list shows each rule’s name, active or inactive badge, Property, Survey, Property sending mode, timing summary and reminder state.

Select the New automation button to create a rule. Select the View activity button for occurrences and delivery evidence, the Edit button to change future evaluation, or the Disable/Enable button to pause or resume it. Pausing prevents new processing while inactive; it does not revoke Invitations, recall messages, erase occurrences or rewrite historical evidence.

Readiness and sending mode

An active rule needs an active Survey in the same Property, an eligible Stay and Guest email, usable message templates, automatic Property sending mode, and an account entitled and allowed to send. In Manual sending mode, the list explains that Automations are paused even when their own Active checkbox is selected.

When a rule becomes due, ELUNIA creates one idempotent occurrence for its initial or reminder stage and then attempts to create or queue the communication. Automation due is not the same as Communication queued. A downstream check can instead produce Skipped evidence.

PMS or provider synchronization, when configured, supplies canonical Stay data. It does not run a separate automation engine. Active integration authority should be corrected at the provider; ELUNIA evaluates the resulting canonical Stay using the same Automation rules.

Empty states and troubleshooting

If no rules appear, confirm Property access and commercial entitlement, then select New automation if permitted. If activity is absent, check active state, automatic sending mode, Survey state, Stay status/dates and minimum nights. ELUNIA does not persist every rejected candidate evaluation, so an absent activity row does not prove one particular rejection reason.

Do not confuse the staff-facing departure reminder digest with a Guest Survey Automation. The digest is an operational summary; it does not create Survey Invitations.

Property language defaults and workflow exceptions

The Languages setup stage establishes the normal Property policy. New workflows normally select Use property language settings — Recommended. Existing explicit workflow choices remain exceptions until changed. The Sending stage shows the effective language and offers Use property settings to remove an exception. Saving Property policy never overwrites exceptions or starts AI.

Readiness follows each active workflow's effective language. Manual requests inherit the Property policy; a one-off choice affects only that request. Unknown preference without configured fallback needs attention. Existing properties without a reviewed policy retain their earlier delivery behavior. See Get your property ready.

In guided setup, Languages covers every feedback experience selected in Step 4, including its reminder before a rule is active. Sending saves a new account’s configuration for review; automatic sending starts only after explicit Go live in Step 7. Existing live rules keep their current behavior and require explicit changes.

Guided setup and pre-arrival

The three touchpoints are Pre-arrival, During the stay and After checkout. Pre-arrival rules use timing before check-in; reminder and delayed delivery remain subject to pre-arrival eligibility. New setup workflows inherit property language settings unless explicitly overridden; usable canonical content does not require a tenant publication. New-account Step 6 stages configuration; only explicit Go live activates planned rules. Existing live rules require explicit changes. Starter, including its trial, does not include Automations. See Prepare your property.

Stop rather than erase operational history

Use Stop automatic sending when a rule should no longer send. This is idempotent and retains its occurrences, invitations and delivery history. Queued initial/reminder work checks the stopped rule and survey before provider execution; messages already being delivered cannot be recalled. An inactive rule is not proof that it has never been used.

The deletion review blocks permanent removal when protected references or uncertain activation history exist. Do not delete an old rule merely to remove a survey from setup: Step 4 separately asks whether each connected rule should keep its state or stop. Editing/viewing a rule does not change its state until an explicit save/action.

In eligible new setup, Step 6 may suggest automatic sending before the first confirmation. The suggestion does not enable it. Confirmed/manual and established-account choices are preserved. If your plan lacks automatic sending, choose manual or Upgrade plan; verified confirmation returns to Sending without enabling rules for you.