Account and Property Scope
Almost every setting in the Operations Platform belongs to one of two levels: your Account (everything you run with LIKE MAGIC) or a single Property. Knowing which level you are on tells you where to make a change, who else it affects, and why a value you set at one level did not appear at the other.
This article is the reference for that model. Individual configuration articles describe what a setting does; this one describes where it lives and how the two levels combine.
1. Who Can Use This Feature?
Your role decides which level you can reach at all:
| Role | What it can reach |
|---|---|
account-admin | Account-wide settings, edit |
account-viewer | Account-wide settings, read-only |
property-admin | Settings of the properties assigned to you, edit |
property-viewer | Settings of the properties assigned to you, read-only |
The Account entry in the property switcher is only offered to users with an administrator or host role. If you only ever see individual properties in the switcher, your role does not include account scope. Ask an Account Administrator, or request the change via a Support Ticket.
See Role and Access Management for the full role model.
2. The Two Levels
Account level is the shared layer. A value set here is the starting point for every property in your account, including properties added later. Some things exist only here, because they have no meaning for a single property: your staff users, your API credentials, your webhook subscriptions.
Property level is one hotel, hostel or building. Values set here apply to that property alone and, where the setting supports it, replace the account value for that property only.
A third, smaller scope sits outside this hierarchy: your own profile. Your interface language and date format are stored on your user, not on the account or a property, and follow you wherever you sign in. See Multi-Language Support.
The two levels are not two separate systems. Property level is a thin layer on top of the account. It stores only the values you deliberately change, and inherits everything else. Nothing is copied, so a later change to an account value reaches every property that has not overridden it.
3. Switching Between Account and a Property
The property switcher sits at the top of the sidebar and shows what you are currently looking at.
- Select the switcher to open the list.
- Choose Account for the account-wide view, or a property name for a single property.
- The screen reloads in the scope you picked.
Behaviour worth knowing:
- If your account has only one property, the switcher is inactive. There is nothing to switch between, so account-wide and property-level settings are listed together in one Settings menu. Everything in this article still applies. You simply never change scope to reach it.
- When your account has more than ten properties, the switcher gains a search field. You can search by property name or by property ID.
- The switcher lists only the properties your role gives you access to.
What happens to the screen you were on. Not every screen exists in both scopes, so switching sometimes moves you:
- Switch to Account while on a screen that only exists per property, and you land on the Inbox.
- Switch from Account to a single property while on an account-only screen, and you land on the Dashboard.
That redirect is not an error. The screen you were on has no meaning in the scope you just selected.
Account scope has a stable address: append ?propertyId=account to a screen's URL to open it at account level directly (for example https://backoffice.<your-tenant-domain>/settings-role-and-access?propertyId=account). Useful for bookmarks and for links you share with colleagues.
4. Which Screens Belong to Which Level
Settings is grouped into sections. Four of them (Guest Journey, Operations, Access and Integrations) hold per-property settings. The fifth, Account, holds the account-wide ones.
a) Account-only
These exist once for the whole account and are not configurable per property:
- Role and Access Management: staff users and groups
- Service Accounts: machine credentials for integrations
- Webhook Subscriptions: where the platform sends event notifications
- Promo Codes: codes usable across the account's properties
When you are on a property and open one of these, the platform switches you to account level first. In the Settings menu, the Account section carries the hint Switches to account level so this is visible before you click.
b) Per-property only
Anything that describes how one building operates: Property Settings, check-in flow configuration, additional services, prepayment, door access, kiosk configuration, the registration form, housekeeping and breakfast views, and guest data retention.
Most operational screens (housekeeping, the front-desk overview) are also per-property: they show the work of the property you have selected. The reservation lists are the exception (see c below).
c) Both levels
Some screens work in either scope:
- The Inbox: at account level it shows conversations across all your properties; on a property it shows that property's conversations only. See Communication Hub (The Inbox).
- Reservations, Arrivals, Departures and In Hotel: at account level they list the reservations of every property you have access to, and a Property filter narrows them to some of them; on a property they show that property's reservations only. See Find Reservations Across Your Properties.
- Guest Notification Filters: listed in the Account section, but it stays open when you switch to a single property. See Guest Notification Filter Configuration.
- My Profile: your personal settings, reachable from either scope.
Then there are the settings that exist as a pair of screens, one per level, which combine as described in section 5. Those are listed in section 6.
If a screen named in this article is not in your Settings menu, it is not part of your setup. Check that your pricing includes it (see Pricing Tiers), that it has been enabled for your property, and that your role allows it. Some screens are reserved for LIKE MAGIC platform operators and never appear for customer accounts.
5. How Inheritance and Overrides Work
For every paired setting, the platform resolves a value in a fixed order. The first one it finds wins:
- the property value, if that property has one
- otherwise the account value
- otherwise the LIKE MAGIC default
So a property override always beats the account, and the account always beats the built-in default. There is no averaging or merging of conflicting values. One level wins.
a) Overrides are sparse
A property does not hold a full copy of the account configuration. It holds only the values you explicitly changed there. Everything you left alone keeps pointing at the account.
This has a consequence worth planning around: change an account value, and it takes effect at every property that has not overridden that particular value (immediately, without you touching each property). Properties that have overridden it keep their own value and are unaffected.
b) The editor tells you which level a value came from
Property-level configuration screens label each field:
- Inherited from the account configuration: no override here; you are seeing the account value.
- Overrides the account configuration: this property has its own value.
- Using value from account / Overrides account default value: on individual fields, with the value the field would fall back to.
- Reset: removes the property override and returns the field to the inherited value. The screen previews what will apply before you confirm.
At account level you see the mirror image: a field that some properties have overridden is marked (for example 3 properties override this), and you can open Properties overriding this value to see which ones and what they use. Use that list before changing an account value. It tells you exactly who will and will not be affected.
c) Two granularities of override
Not every setting overrides at the same size, and this is the most common source of surprise:
- Field by field. Theme and language/locale settings override one field at a time. Set a property's primary colour and it overrides only the colour; typography, logo and everything else keep inheriting.
- Block by block. Some settings override as a whole group. Guest access configuration is one: if a property defines its own, the entire block comes from the property, and the account's values for that block no longer contribute. Filling in one field of such a block means you own all of it.
Where a screen groups fields under a heading such as Property Specific Config (described in the UI as Override the account configuration for this property), that group is the unit of override.
Before overriding a block-level setting, note the account values you still want. They are not merged in once the property owns the block.
d) Some parts of a paired screen are property-only
A screen existing at both levels does not mean every field on it does. Guest notification configuration is the clearest example: general settings and message templates are inherited from the account and can be overridden per property, but the timing rules (when each notification is sent) exist only at property level and must be set on each property. See Guest Notification Settings.
6. Where to Edit What
| Setting | Account page | Property page | How they combine |
|---|---|---|---|
| Theme | Settings → Account → Theme | Settings → Operations → Theme | Field by field |
| Language & Locale | Settings → Account → Language & Locale | Settings → Guest Journey → Language & Locale | Field by field |
| Guest Notifications | Settings → Account → Guest Notifications | Settings → Guest Journey → Guest Notifications | Field by field; timing rules are property-only |
| Payments | Settings → Account → Payments | Settings → Operations → Payments | Property inherits until it overrides |
| Second Screen | Settings → Account → Second Screen | Settings → Operations → Second Screen | Property inherits until it overrides |
Detail for each of these lives in its own article: Theme Configuration, Multi-Language Support, Guest Notification Settings, Payment Configuration, and Set Up and Manage Second Screen Devices.
A working order for a multi-property account:
- Set the shared behaviour once at account level.
- Add properties: they inherit it, including properties provisioned later.
- Override only the properties that genuinely differ.
- Before changing an account value later, check the overriding-properties list on the field so you know who it will reach.
7. Troubleshooting
I changed a setting at account level and one property did not follow. That property has its own override for that value. Open the property's screen and either Reset the field or edit it there.
I changed a setting on a property and nothing happened elsewhere. Expected. A property override applies to that property alone. To change every property, edit the account value instead.
A menu item disappeared when I switched scope. The item exists only in the other scope. Section 4 lists which is which.
Switching scope moved me to the Inbox or the Dashboard. The screen you were on does not exist in the scope you switched to, so you were taken to one that does.
I cannot find the Account entry in the switcher. Your role has no account scope, or your account has a single property (in which case the switcher is inactive and everything is in one menu).
A field is read-only. You hold a viewer role (account-viewer at account level, property-viewer on a property). Ask an administrator to make the change.
I filled in one field of a block and lost the account's other values. That block overrides as a whole (section 5c). Re-enter the values you need on the property, or remove the property override entirely to go back to inheriting.
8. FAQs
If I override a value on a property, does it stop following the account forever?
Only for that value, and only until you reset it. Reset removes the override and the field inherits again.
Does a new property start with my account settings?
Yes. A new property has no overrides, so it inherits every account value from the moment it is created.
Can I see which properties differ from my account configuration?
Yes. At account level, an overridden field shows how many properties override it, and the Properties overriding this value list names them and shows their values.
I only have one property. Does any of this matter?
The model still applies, but you never switch scope: account-wide and property-level settings appear together in one Settings menu, and there is nothing to override.
Why can I edit a setting on one property but not another?
Property roles are assigned per property. You hold an editing role on the first and a viewer role (or no role) on the second.
9. Conclusion
The Operations Platform resolves configuration from the property up: property value, else account value, else the LIKE MAGIC default. Property overrides are sparse, so an account change reaches everything that has not deliberately diverged. Set the shared behaviour once at account level, override only where a property genuinely differs, and use the overriding-properties list before you change a shared value.
For orientation in the platform itself, see How to Navigate through the Operations Platform.