# Tenants
## Tenants overview
[Tenants ](#user-content-fn-1)[^1]\(previously called *Stores*) functionality gives a possibility to add many tenants with different currencies, codes, and names. Each tenant has its own database with a Members List, Translations, and so on. Members realize transactions within each tenant according to the currency and code. After creating several tenants, in the top left corner, you’ll see a drop-down list where you can select a tenant. Once the tenant is selected, all the displayed data is exclusive to that selected tenant. There are 6 areas where the drop-down list is not visible: Configuration, Administrators, Roles, Transactions, Tenants, My Profile. In all of the above, settings will apply to all the tenants.
To access Tenant list, go to **Settings ->** **Tenants**. All created tenants will be listed in the table. You can change the number of rows displayed per page by clicking on the arrow icon below the table and picking a handy number from the list.
#### Filtering Tenants
You can search for the record via the **+ADD FILTER** feature. Clicking on the button will expand the list which contains the search field and available options. You can pick either relevant option from the list or type it in the search field.
* Filter options:
* Name
* Code
* Currency
* Active
* When choosing the option, a pop-up screen will show up, where you can add conditions and values to list only proper records. To remove the filter click on 'X' on the filter chip.
* When the filter option, the index next to **+ADD FILTER** button will change and show the amount and percentage of the currently listed option.
***
## Adding tenant
To add a new tenant click on the +**ADD TENANT** button, you will land on the next screen.
All fields must be filled, so you will need to add **Currency** (you pick this value from the list), **Code**, and **Name**. Also please remember to check the **Active** box (you define here if the tenant is active or inactive). When you want to submit the form, click on the **ADD TENANT** button.
A new record will be present on the 'Tenant list' screen
## Managing tenants
### Editing tenant
If you want to edit the tenant click on the overflow button, and from the list click on **Edit tenant**. You will land on the edit screen, where you can change the tenant name and state (active/inactive). Such fields as currency or code are not editable. After changes, click **EDIT TENANT** to save.
***
## Timezone
Open Loyalty supports two **timezone strategies** that define how campaign availability, limits, and reward redemptions are calculated across different time zones.
This setting is configured at the **tenant level** and applies globally to campaigns, rewards, transactions, and custom events.
#### Available strategies
**Default (recommended)**
Uses the **tenant’s timezone** for all date and time calculations.
* Campaign activity periods (`startsAt`, `endsAt`, time-of-day)
* Member limits (hourly, daily, weekly, etc.)
* Reward availability and redemption limits
This strategy is best suited for loyalty programs operating in a **single timezone** or where consistent business time is required.
**Local time**
Uses the **event’s local datetime without timezone conversion**.
This strategy is designed for loyalty programs whose members:
* Are distributed across multiple time zones
* Travel frequently
* Perform actions based on their local time (for example: *“one workout per day”*)
{% hint style="warning" %}
When **Local time** is selected, we recommend setting **UTC** as the tenant's timezone for consistency.
{% endhint %}
***
### How Local time works
When local time is enabled:
#### Campaign availability
* Campaign activity is validated **against the event datetime as provided**, without converting it to the tenant timezone.
* If a campaign is active from **14:30–16:30**, it is available in **any timezone where the local time is within that range**.
Example:
* `14:30+02:00` → campaign available
* `14:30+09:00` → campaign available
The system does **not** normalize times to the tenant timezone.
***
#### Member limits
All member limits (hourly, daily, weekly, monthly, yearly) are calculated using the **local date and time of the event**.
This means:
* Two members performing the same action at the same moment but in different time zones are evaluated **independently**
* Hourly and daily limits are applied based on each member’s local clock
Example:
* Member A: `09:20+02:00` → counts toward hour **09**
* Member B: `16:20+09:00` → counts toward hour **16**
***
#### Points expiration
If points are granted with an expiration (e.g. **2 hours**), they expire **exactly 2 hours from the event time**, not from the tenant’s business date.
***
#### Rewards and redemptions
The same local-time logic applies to rewards:
* Reward availability
* Reward visibility
* Redemption limits
The reward redemption date can be explicitly provided and is evaluated using the selected timezone strategy.
***
### API behavior with Local time enabled
#### Passing timezones
External systems (for example, mobile apps) can control time calculations by passing the timezone explicitly:
```
X-Timezone: Europe/Warsaw
```
This header is used when:
* Fetching available campaigns
* Calculating limits
* Resolving availability windows
***
#### Event and transaction dates
When creating data:
* `purchased_at`
* `event_date`
* `redemptionDate`
You may pass datetimes **with any timezone**.
When retrieving data:
* Returned dates preserve the **original timezone** provided during creation.
***
### When to use Local time
Choose **Local time** if:
* Your loyalty program operates globally
* Limits should reset based on the user’s local day
* Campaigns depend on *local time of action*, not tenant business time
Choose **Default** if:
* Your program operates in a single timezone
* You require strict tenant-based accounting and reporting
[^1]: previously called *Stores*
