A guest who gave marketing consent at one of your properties often turns up later at a sibling property in the same group. Mapping the consent column to a consent's UUID rather than its code lets a Property Data Importer import find that consent anywhere in your organisation, instead of only at the property being imported into.
The alternative is asking the guest to consent again, or creating a duplicate consent at every property. Neither is good for you or for them.
The two ways to attach a consent
consent:consent_codematches a consent code that exists at the property you are importing into.consent:uuidmatches a consent by its unique ID, anywhere in your organisation, including one created at a different property.
Attaching by UUID does not move or copy the consent. It still belongs to the property that created it. All this changes is where an import is allowed to look.
When you would use it
A chain feeds guest data from a central PMS, and the consent was originally captured at a different property in the group.
You are standardising how properties reference the same consent, rather than keeping a separate one per property.
You are migrating from a system that already tracks consent by UUID rather than by code.
Setting it up
There is nothing to switch on. consent:uuid is available to every organisation.
Tell your Bookboost onboarding or support contact that you want the consent column in your import mapping set to
consent:uuid.Make sure the value in that column is the UUID of the consent, not its code.
The mapping is configured with Bookboost, the same as any other Property Data Importer field. If you are not certain where the UUID comes from in your source system, check before switching a live import over.
What this does not do
It does not search other organisations. A UUID belonging to a consent in a different organisation is not matched, and the row fails with consent not found, exactly as an unrecognised code does.
It does not warn you if you map both fields. Where a row carries both
consent:uuidandconsent:consent_code, the UUID wins and the code is ignored, silently. Nothing flags that the two disagree, so do not map both unless you mean the UUID to win.It does not change how consent is created or owned. Consent records are still created and stored at property level.
It does not merge anything. Two consents in two properties remain two consents.
Common questions
Does this merge consent across our properties into one record?
No. Each consent still belongs to the property that created it. UUID mapping only lets an import at another property in the same organisation find and attach it.
What happens if the UUID does not match anything?
The row fails to import and is recorded as consent not found, whether the UUID is wrong or belongs to a consent in a different organisation.
Can we keep using consent_code for properties that do not need this?
Yes. Existing consent:consent_code mappings are unaffected.
What to do next
For the full list of import mapping fields, see Property Data Importer Fields Available. For what each consent status means, see Consent management essentials.
Getting help
Open Help at the bottom of the left menu and choose Talk to Us, or email support@bookboost.io.