Cache configuration and data synchronization between Asset and Workplace

• 1. Introduction: Data Synchronization Between Asset and Workplace
• 2. What Is Caching?
• 3. Asset Cache vs Workplace Data Refresh
  • 3.1 Asset-side caching
    • Automatic cache refresh
  • 3.2 Workplace-side data refresh
• 4. Cache configuration in the API Connector
  • 4.1 Cache items and metrics
  • 4.2 Forcing a Manual Cache refresh
• 5. Cache details per type of data
  • 5.1 Buildings & Areas
    • 5.1.1 Cache Behaviour on Asset Side
    • Is this data cached?
    • 5.1.2 Automatic Cache Recalculation
    • 5.1.3 How and How Often Workplace Requests This Data
  • 5.2 System Users
    • 5.2.1 Cache Behaviour on Asset Side
    • 5.2.2 Automatic Cache refresh
    • 5.2.3 How and How Often Workplace Requests This Data
  • 5.3 Assets, Catalog Items & Related Categories
    • 5.3.1 Cache Behaviour on Asset Side
    • 5.3.2 Automatic Cache refresh
    • 5.3.3 How and How Often Workplace Requests This Data
  • 5.4 Reservable Details of Areas, Assets & Catalog Items
    • 5.4.1 Cache Behaviour on Asset Side
    • 5.4.2 Automatic Cache refresh
    • 5.4.3 How and How Often Workplace Requests This Data
  • 5.5 Cost Centers
    • 5.5.1 Cache Behaviour on Asset Side
    • 5.5.2 Automatic Cache Recalculation
    • 5.5.3 How and How Often Workplace Requests This Data
  • 5.6 Service Types
    • 5.6.1 Cache Behaviour on Asset Side
    • 5.6.3 Automatic Cache Recalculation
    • 5.6.3 How and How Often Workplace Requests This Data
  • 5.7 Access Restrictions, Blocked Dates & Regimes for Reservable Objects
    • 5.7.1 Cache Behaviour on Asset Side
    • 5.7.2 Automatic Cache Recalculation
    • 5.7.3 How and How Often Workplace Requests This Data
  • 5.8 Reservations

1. Introduction: Data Synchronization Between Asset and Workplace

Workplace relies on master data managed in Asset to support its core functionality, such as reservations, service requests, colleague selection, and access validation.
To make this possible, Workplace retrieves a structured set of data elements from Asset—ranging from buildings and areas to assets, catalog items, users, cost centers, service types, and more.

Because Workplace needs to show real-time availability and up-to-date configuration options, the synchronization between the two systems must be both accurate and efficient. Some data types change frequently, while others remain relatively stable. Some data is needed globally by many users, while other information depends on the individual user context. All of these differences influence how the data is retrieved and whether caching is applied.

2. What Is Caching?

Caching is a mechanism used to temporarily store the results of data retrieval so that the same information can be returned faster the next time it is requested.

In the context of Asset and Workplace, caching means that Asset pre-calculates or retrieves certain data once and then stores it for reuse. When Workplace requests that data again—often many times throughout the day—Asset can respond immediately without having to reprocess the data from scratch.

This provides several benefits:

• Shorter response times for Workplace users
• Less load on Asset, especially for data that is complex to calculate or retrieved frequently
• More predictable performance during peak usage

However, caching is only useful for data that does not change every minute.
Therefore, only certain types of master data are cached (for example: buildings, areas, assets, system users, service types). Data that must always reflect the real-time state (such as reservations) is never cached.

3. Asset Cache vs Workplace Data Refresh

Caching happens at two different levels in the overall data flow between Asset and Workplace:

1. Asset-side caching
2. Workplace-side data refresh intervals

These two mechanisms work together but operate independently.

3.1 Asset-side caching

Asset determines how master data is retrieved, cached, and refreshed before Workplace receives it.
Depending on the data type, one of the following caching mechanisms applies:

Warm-up cache

Warm-up cache items are generated automatically at the start of each day.
Because the cache is prebuilt before any user requests the data, the first request of the day is already fast.

A warm-up cache offers the best possible performance, as it always returns results immediately—regardless of how many times the data is requested or by whom.

However, warm-up caching is only feasible when:

• The data is requested using the same filter every time, and
• The data does not depend on the individual user making the request.

If the result would differ per user or per filter, a warm-up cache is not suitable.
For these types of data, an at-response cache is used instead.

At-response cache

An at-response cache is created only after the data is requested for the first time that day by a specific user and with a specific filter.

From that moment on:

• Subsequent requests by the same user with the same filter reuse the cached result for the rest of the day.

This avoids repeated recalculation while still allowing user- or filter-specific results that warm-up caching cannot support.

No cache
Used for data that must always be retrieved in real time, such as reservations or user-specific access checks.

Automatic cache refresh

For cache-enabled data types, Asset automatically invalidates and, in case of warm-up cache, recomputes the cache when relevant changes occur. Examples include adding or removing objects from the API Connector or modifying fields that are part of the synchronized dataset.

The exact conditions under which a cache is invalidated differ per data type.
These details are described individually in each chapter below.

Even if an automatic cache invalidation does not occur for some reason, all cache items are fully recomputed or cleared every night:

3.2 Workplace-side data refresh

Even if Asset has the latest data available—whether cached or recalculated—Workplace itself only fetches some data periodically.

This means that data in Workplace may appear out-of-date temporarily, not because Asset still has old information in cache,but because Workplace has not yet retrieved the latest version.

For example, Workplace might only refresh certain datasets every X hours.
Until that next refresh moment occurs, the older version will still be shown in the interface.

Each master data section, later in this documentation, explains:

• How often Workplace retrieves that specific dataset
• Whether the data is cached in Asset
• When Asset automatically recalculates the cache
• How to manually reset Asset’s cache if needed

Together, this gives a full picture of how data flows and stays up-to-date between both systems.

For a more technical overview of the way Workplace fetches the data from Asset, see: Axxerion data polling (This article is only available for Spacewell employees).

4. Cache configuration in the API Connector

The actual data that is synced between Asset and Workplace is linked via the Workplace Experience API Connector. For more information about linking the data, see: API Connector

4.1 Cache items and metrics

Within the API Connector, each data type that supports caching has a corresponding cache item.
These items allow you to view the current cache status and the usage metrics, including:

• Hits – The data was requested by Workplace and the cache was used.
• Misses – The data was requested, but no cache was available (for example, the first request of the day for an on-demand cache).

For on-demand cache items, a miss is expected the first time the data is requested each day.

Accessing cache configuration

Cache configuration is available via the Cache configurations include on the Workplace API Connector. By default only the active cache configuration is shown, with an option to show all cache configurations, via the button 'Also show inactive cache configurations':

The cache configuration is disabled by default for a new customer. After activating the Workplace Experience module, the implementation consultant must enable the cache configuration (this is described in the corresponding module activation).

To enable it:

1. Click 'Also show inactive cache configurations' button to show all cache configurations
2. Open the relevant cache configuration (use the highest-version entry if multiple versions exist).
3. Click ‘Enable’.

Cache items
The cache configuration displays a list of the cache items related to the different types of data used by Workplace.

Opening a cache item shows details about that specific item:

Most fields within a cache item are not required to understand the general caching behavior.
This documentation explains only the relevant aspects, and additional details are provided per data type in the sections below — including which cache item belongs to which data set.

4.2 Forcing a Manual Cache refresh

For most cached data types, a manual cache recompute is usually not required.
Relevant changes to the underlying data will, in many cases, trigger an automatic cache refresh. Whether automatic cache refresh applies—and which updates trigger it—is described individually for each data type in the sections below.

However, if cached data appears outdated or the synchronization does not behave as expected, you can manually clear and rebuild the cache.

To do so:

1. Open the cache item associated with the specific data type
   (the mapping between cache items and data types is described per data type section below).
2. Click the ‘Clear cache’ button to trigger a recomputation.
   
   N.b: This resets the “size” of the cache (as seen in the Metrics field) to 0 (found 0). Be aware that a “clear cache” operation will take at least 10 seconds to take effect. This built-in delay prevents automatic cache refresh from occurring too quickly (such as when importing new objects that are automatically added to the API Connector), which would otherwise result in constant cache recomputation. Therefore, wait at least 10 seconds after using “clear cache” before refreshing the page to see the correct results (size of 0). Once the cache refresh is complete, the last compute time is updated so that it reflects when the cache refresh was completed the last time.

5. Cache details per type of data

The following types of data are synchronized between Asset and Workplace:

• Buildings and areas (including rooms, workplaces, and parkings)
• System users
• Reservable assets (shown in Workplace as “Equipment”)
• Categories of reservable assets (used for filtering in Workplace)
• Reservable catalog items (shown in Workplace as “Services”)
• Categories of reservable catalog items (used for filtering in Workplace)
• Reservable details for areas, assets, and catalog items (e.g. reserve-in-advance settings)
• Cost centers
• Service types (relevant for the service request integration)
• Access restrictions for reservable areas, assets, and catalog items (this determines availability per user)
• Blocked dates for reservable areas and assets (makes objects unavailable on specific dates)
• Regimes for reservable areas and assets (make objects unavailable during specific periods)
• Reservations

Most of the data types listed above use caching on the Asset side in some form.
In the following chapters, each data type is described in detail, including:

• What information it contains
• Whether and how it is cached
• Which cache items are involved
• When automatic cache refresh occurs
• How Workplace retrieves and refreshes the data
• Whether manual cache recomputation may be needed

These sections provide a complete overview of how each dataset behaves in the synchronization between Asset and Workplace.

5.1 Buildings & Areas

Buildings and areas are master data elements added to the Workplace API Connector and synchronized from Asset. They contain the basic information required for Workplace to function correctly.
The data sync relies on two script reports in Asset, which provide insight into the data that is being transferred.

This data is fetched by Workplace via reports, and as a result, these reports can also be viewed from within Asset:

Building data – Report: COBUNDU-003
Contains the core building information, such as:

• Name
• Category
• Photo
• Parent building
• Timezone

Area data – Report: COBUNDU-011
Contains the core area information, such as:

• Name
• Category
• Photo
• Reservable (true/false)
• Capacity
• Parent area
• QR code

5.1.1 Cache Behaviour on Asset Side

Is this data cached?

Yes. Both building and area data are cached through the following cache items:

Building data:
Cache item: All tagged buildings via COBUNDU-003 ScriptReportAllProperties

This cache item is cached at response.

Area data:
Cache item: All tagged areas via COBUNDU-011 ScriptReportAllPropertysAndAreas, when requested by the general admin user

This cache item is cached via warm-up.

5.1.2 Automatic Cache Recalculation

The cache is automatically recomputed when relevant master data changes occur in Asset. This includes:

• Adding or removing buildings or areas in the API Connector (affects the corresponding cache item)
• Updating any synchronized field on a building or area (e.g. name, photo, category, etc.)

The cache recomputation may take anywhere from a few seconds up to several minutes, depending on the size of the dataset.

For a manual cache refresh, see above: Forcing a Manual Cache Recompute

5.1.3 How and How Often Workplace Requests This Data

• Building data is requested by Workplace once every hour via the general admin user.
  As a result, changes made to buildings in Asset may take up to 1 hour to become visible in Workplace.

  • Changes to the photo of the buildings in Asset take longer to take effect in Workplace, as photos are synced only once per day.

• Area data is requested once every 30 minutes via the general admin user. As a result, changes made to areas in Asset may take up to 30 minutes to appear in Workplace.

  • Changes to the photo of the areas in Asset take longer to take effect in Workplace, as photos are synced only once per day.

5.2 System Users

System user data is used by Workplace for two purposes:

1. To validate that a Workplace user is linked to an active system user in Asset.
   This validation is performed when the user logs into Workplace, using the IWMS field on the Workplace user, which contains the username of the corresponding Asset system user.
2. To retrieve the complete list of colleagues used in Workplace features such as Favorites and Book on behalf, where users need to select another colleague.

This data is fetched by Workplace via a report, and as a result, this report can also be viewed from within Asset:

System users – Report: COBUNDU-002
This report includes system user and related contact information, such as:

• Username
• Contact full name
• QR code
• Photo
• Enabled/disabled status

5.2.1 Cache Behaviour on Asset Side

Is this data cached?

Yes, the complete list of system users is cached on Asset side via:

Cache item: ‘All tagged system users via COBUNDU-002 ScriptReportVerifyUser, when requested by the general admin user’

This cache item is cached via warm-up.

5.2.2 Automatic Cache refresh

The cache is recalculated automatically when:

• A system user is added to or removed from the API Connector.
• Contact-related fields are updated (e.g., contact name, photo).

Updates on the system user object itself (enabled/disabled state) do not trigger an automatic cache refresh. However, Workplace separately requests all the system users who have been updated in the last hour (based on a “last updated” filter) every hour. This does include these updates to the system user. This filtered result is not cached on the Asset side.

For a manual cache refresh, see above: Forcing a Manual Cache Recompute

5.2.3 How and How Often Workplace Requests This Data

Checking whether a Workplace user is linked to an active system user in Asset is performed in real time when the user logs in to Workplace. As a result, the user will also be included in the colleague list that other users can select in features such as Favorites and Book on behalf.

If a new user does not log in shortly after being added, their details will be retrieved during the periodic synchronization, which runs once every hour. Until that sync has occurred, the user may not be visible in Favorites or Book on behalf.

Changes to existing users (for example, enabling/disabling the user in Asset) are also applied via the hourly sync. As a result, it can take up to one hour before a user becomes visible again (after being enabled) or disappears (after being disabled) in the colleague selection list used by Favorites and Book on behalf.

User photos can take longer to update in Workplace, since photos are synced only once per day.

5.3 Assets, Catalog Items & Related Categories

Reservable assets (equipment) and catalog items (services) are the master data elements used by Workplace when creating reservations for equipment or services.
Because Workplace allows users to filter on categories, the (translated) category names for both assets and catalog items are also included in the sync.

This master data type does not use a standard Asset report. Instead, this uses a hardcoded filter to retrieve the relevant objects.
The resulting dataset cannot be viewed directly in Asset, but it includes the core information needed in Workplace:

• Name
• Quantity
• Reservable flag
• Photo
• Category

5.3.1 Cache Behaviour on Asset Side

Is this data cached?

Yes. This data is cached through 4 cache items:

• Tagged assets (equipment)
• Categories related to the tagged assets (equipment)
• Tagged catalog items (services)
• Categories related to the tagged catalog items (services)

These cache items are cached at response.

5.3.2 Automatic Cache refresh

The cache for reservable assets, catalog items, and their categories is recalculated automatically when:

• An asset or catalog item is added to or removed from the API Connector.
• Any relevant field of an asset or catalog item is updated (e.g. name, photo, quantity, category).

These changes trigger the corresponding cache item to be refreshed.

For a manual cache refresh, see above: Forcing a Manual Cache Recompute

5.3.3 How and How Often Workplace Requests This Data

The data related to assets (equipment in Workplace) and catalog items (services in Workplace) is requested by Workplace once every hour via the general admin user.
As a result, changes made to assets or catalog items in Asset (for example, adding new items, or renaming them) may take up to 1 hour to become visible in Workplace*.

The data related to the categories of assets and catalog items (currently only the category name) is retrieved in real time per user. This means that name changes to a category are reflected immediately.

However, changing the category assigned to an asset or catalog item is treated as a change to the asset or catalog item itself. These updates follow the hourly refresh cycle and may take up to 1 hour to appear in Workplace.

*Changes to photos of the Assets and catalog items can take longer to update in Workplace, since photos are synced only once per day.

5.4 Reservable Details of Areas, Assets & Catalog Items

In previous sections, the master data for areas, assets, and catalog items was described.
The reservable details associated with these objects are retrieved and cached differently, so they are documented separately.

This data does not use a standard Asset report.
Workplace retrieves it using a hardcoded filter, and the resulting data cannot be viewed directly in Asset.

The dataset includes the reservable-specific settings required by Workplace, such as:

• Setup and tidy-up times
• Reserve-in-advance times
• Whether catering is allowed (for areas)
• The building in which catalog items (services) are available (an empty building means available for all buildings)

5.4.1 Cache Behaviour on Asset Side

Is this data cached?

Yes. The reservable details are cached using three cache items:

• Reservable details (all tagged resources)
• Reservable details related to the tagged assets (equipment)
• Reservable details related to the tagged catalog items (services)

Which cache item is used depends on the type of data Workplace requests:

• For areas, Workplace uses:
  Reservable details (all tagged resources)
• For assets (equipment), Workplace uses:
  Reservable details related to the tagged assets (equipment)
• For catalog items (services), Workplace uses:
  Reservable details related to the tagged catalog items (services)

These cache items are cached at response.

Note: There are also specific cache items for workplaces, rooms, and parkings, but these are currently not used by Workplace.

5.4.2 Automatic Cache refresh

The cache for reservable details is automatically recalculated when:

• An area, asset, or catalog item is added to or removed from the API Connector.
• Any reservable-related field is updated on the object, including:

  • Set-up/tidy-up times

  • Reserve-in-advance times
  • Catering-allowed settings
  • Setting the building of the asset or on the reservable settings of the catalog item*

Any such update triggers the associated cache item to be refreshed.

*Currently, emptying the building of the asset or on the reservable settings of the catalog item does not result in an automatic cache refresh and requires a manual cache refresh or waiting until the nightly update if no other changes will trigger the automatic cache refresh.

For a manual cache refresh, see above: Forcing a Manual Cache Recompute

5.4.3 How and How Often Workplace Requests This Data

The data related to the reservable settings of areas, assets (equipment in Workplace) and catalog items (services in Workplace) is requested by Workplace once every hour via the general admin user.
As a result, changes made to settings like ‘Reserve in advance’ may take up to 1 hour to become visible in Workplace.

*Specifically, the building of the catalog item or asset is fetched in real time when a user is looking for services or equipment to book, and as a result, changes to the building of the asset or the catalog item (indirectly via the reservable linked to it) will take effect directly in Workplace. However, be aware of the previous part, which described certain changes that will or will not cause an automatic cache refresh in Asset

5.5 Cost Centers

Cost centers added to the API Connector can be used in Workplace to link a cost center to a reservation.
This data does not use a standard Asset report. Instead, Workplace applies a hardcoded filter to retrieve the relevant cost center objects.
The resulting dataset cannot be viewed directly from within Asset.

The data includes only the basic information required by Workplace:

• Name
• Reference

5.5.1 Cache Behaviour on Asset Side

Is this data cached?

Yes. Cost center data is cached via two cache items:

• Tagged cost centers, when requested by the general admin user
• Tagged cost centers

The first one is done via warm-up cache. The second one is done via at response cache.

5.5.2 Automatic Cache Recalculation

The cache items for cost centers are automatically recalculated when:

• A cost center is added to or removed from the API Connector.
• Any relevant cost center field is updated (e.g. name or reference).

Any such update triggers a refresh of the appropriate cache item.

For a manual cache refresh, see above: Forcing a Manual Cache Recompute

5.5.3 How and How Often Workplace Requests This Data

The data related to the cost centers is retrieved in real time per user.

Since the request always contains at least 3 characters, as this is required in Workplace to look for cost centers, this is always very fast.

5.6 Service Types

Service types added to the API Connector are used by Workplace as part of the service request integration.
This data does not use a standard Asset report. Instead, Workplace retrieves the service types using a hardcoded filter.
The resulting data cannot be viewed directly in Asset.

The dataset contains basic service type information required by Workplace:

• Reference
• Name
• Parent service type
• Keywords

5.6.1 Cache Behaviour on Asset Side

Is this data cached?

Yes. Service type data is cached via the following cache item:

• Tagged service types

This cache item is cached at response.

5.6.3 Automatic Cache Recalculation

The cache for service types is automatically recalculated when:

• A service type is added to or removed from the API Connector.
• Any relevant field on a service type is updated (e.g. name, keywords, parent type).

For a manual cache refresh, see above: Forcing a Manual Cache Recompute

5.6.3 How and How Often Workplace Requests This Data

The data related to the service types is retrieved in real time per user.

5.7 Access Restrictions, Blocked Dates & Regimes for Reservable Objects

Access restrictions, blocked dates, and regimes determine which users may reserve specific resources (areas, assets, or catalog items) and under which conditions.

When retrieving a list of reservable resources, Workplace requests the availability of those resources for a given time period. As part of this request, it also retrieves:

• Any blocking reasons [no access, unavailable due to regime or due to a blocked date]
• For regimes and blocked dates, the applicable time period of the block

This information is used in Workplace to show only available resources, or display the reason why a resource is unavailable on floor plans or in specific resource timelines

5.7.1 Cache Behaviour on Asset Side

Is this data cached?

Yes. This data is cached using the following cache items:

• Access users have to tagged areas
• Access users have to tagged assets (equipment)
• Access users have to tagged catalog items (services)
• Regimes or blocked dates related to tagged objects (areas, assets, catalog items)

The caching mechanism differs from other data types and also differs between:

• Access-related cache items
• Regime and blocked-date cache item

Access Cache Behaviour

Access to reservable resources is user-specific. However, many users share the same combination of access groups.

To optimize performance:

• Each night, for every floor (and as a combined set for every building), the system pre-calculates the access rights for each unique combination of user access groups.
• These results are stored in the database as a warm-up cache.

As a result, loading a floor plan and searching for reservable resources within an entire building or specific floor is very fast in Workplace, as it uses this pre-calculated warm-up cache.

Regimes & Blocked Dates Cache Behaviour

Regimes and blocked dates are not user-dependent, but time-dependent.

Therefore, they are cached differently:

• The first request of the day for a specific time period and building or floor (regardless of which user makes the request) is calculated and stored in cache.
• Any subsequent identical request (same location, same time period) uses this cached result.

As a result:

• The first user requesting availability for a specific period (for example, reserving a workplace for the next day in a specific building) may experience a slightly slower response.
• Subsequent users requesting the same data that day will experience much faster performance.

5.7.2 Automatic Cache Recalculation

Access Cache

The cache for user access to reservable resources is automatically recalculated when:

• The setting “Skip access check when searching for reservables” in the API Connector is turned on or off
• Access rights of a user are modified (for example, adding or removing access rights)

However, some updates do not trigger an automatic recalculation, to prevent excessive overhead and performance degradation. For example:

• Changing access settings on the resource itself (for example, setting access to none for a specific resource or category for certain system groups)

To manually force a cache invalidation, see above: Forcing a Manual Cache Recompute .

Be aware:

• Recomputing the cache may take time if the dataset is large.
• During the rebuild process, the previous cache remains active, therefore, manually invalidating access-related cache items should not result in performance degradation while the new cache is being rebuilt.
• As mentioned above, every cache item is automatically invalidated every night, so changes should always* be visible in Workplace the next day
  

Regimes & Blocked Dates Cache

The cache for regimes and blocked dates is automatically recalculated when:

• The setting “Skip blocked date check when searching for reservables” is turned on or off
• The setting “Skip regime check when searching for reservables” is turned on or off

However, the following updates do not trigger automatic recalculation:

• Adding, removing, or modifying regimes or blocked dates on a reservable resource

This is intentional to avoid excessive recalculation overhead.

To manually force a cache invalidation, see above: Forcing a Manual Cache Recompute .

Be aware:

• As this cache does not use a warm-up mechanism, after a cache refresh, the first request for a specific floor/building and time period will be recalculated and stored.
• This means the first request after a refresh may be slower and only subsequent identical requests will use the cached results again and be faster.
• As mentioned above, every cache item is automatically invalidated every night, so changes should always* be visible in Workplace the next day

5.7.3 How and How Often Workplace Requests This Data

Workplace requests this data every time a user views or searches for reservable resources, including:

• Searching for available rooms, workplaces, or services
• Creating a new reservation
• Opening a floor plan
• Viewing the reservation calendar

Because this data is requested in real time during user interactions, depending on the cache behavior is essential for maintaining acceptable performance.

5.8 Reservations

Reservations represent all actual bookings created by users in Workplace or Asset.
Because they determine the real-time occupancy and availability of areas, assets, and catalog items, reservation data must always be live and up to date. For this reason, reservations are never cached.

Caching reservation data would be counterproductive because:

• Every new reservation, update, or cancellation would immediately refresh the cache.
• These changes occur continuously throughout the day.
• Real-time accuracy is essential to prevent double bookings, validate availability, and provide correct timelines in Workplace.

Therefore, reservations are always retrieved directly from Asset in real time.