Space Settings

Click the ellipsis (...) on a space and select Settings. The settings drawer has three tabs:

• General — the space's name, location, time zone, temperature units and priority modifier.
• Incidents — how long Xyte waits before notifying you about an incident in this space, and where those notifications are routed.
• Access — who can see and manage the space.

General

In the General tab, you can do the following:

• Change the name of the selected space.
• Provide a location and time zone for the space.
• Select a unit of measure for temperature (Celsius or Fahrenheit) for the space.
• Set a priority modifier for this space. If set, this will affect any incident detected in this space and alter it to have a higher or lower priority than the default. For example, all incidents in the showroom can be configured to automatically be set to a higher priority than incidents in regular spaces. The priority options are:
  • High priority
  • No change (default)
  • Low priority
• Provide a custom space ID that will be sent to the relevant integration providers when incidents are reported.

📘

What the space time zone controls

The time zone on a space is the time zone Xyte hands down to the devices in it — connected devices take their local time from this setting rather than from themselves. Child spaces inherit the time zone from their parent space unless you give them one of their own, so setting it once at the top of a branch applies it to every space beneath it; where no time zone is set anywhere up the tree, a space falls back to UTC. Device telemetry is stamped with that local time, so a wrong or missing time zone makes timestamps arrive skewed by the size of the offset. Because the platform decides a device is offline from how recently it reported, badly skewed timestamps can raise offline incidents for devices that are working normally. If devices in one branch of a tree show the wrong local time, check the time zone on that space and on every space above it, and re-check after a daylight-saving change.

Incidents

The Incidents tab controls two things for this space: when an incident notification is sent, and where it goes.

Incident notification delay

At the top of the tab you can set an Incident Notification Delay for the space. This controls when an incident notification is sent — not when a device is detected as offline.

When a delay is set, a newly opened incident must stay open longer than the delay before any notification goes out. If the issue clears on its own within that window — for example, a device that briefly drops after a missed poll or a short network hiccup and then comes right back — the incident is closed and no notification is sent at all (neither the "opened" nor the "closed" notification). Genuine, sustained issues still notify you once the delay elapses.

Use the slider, or the numeric field beside it, to set a delay from Off up to 60 minutes. A few minutes is usually enough to filter out short-lived, self-recovering alerts; set it to Off to be notified immediately.

Routing

Below the delay, the Routing section decides where incidents from this space are sent — and lets you override that per space, so different locations can notify different channels.

❗️

Set up the integration first

Per-space routing is an override on top of a working integration — not a replacement for one. Before you configure anything here, connect the integration itself under Connections → Integrations (for Microsoft Teams: the Messaging Platforms tab, with a Webhook URL saved and the integration showing Active).

The Routing section lists every supported channel, connected or not. A channel you have not connected shows "<channel> integration not enabled" in place of its settings, with a link straight to where you connect it — so there is nothing to fill in here until the integration itself is Active.

In the capture below, none of the channels have been connected yet — so every card says exactly that and links straight to where it is set up.

Each channel appears as its own card:

• An Off / On switch controls whether that channel reports incidents for this space at all.
• An Inherit events from parent toggle controls where those incidents go. Leave it on and the space follows its parent space — and, at the top of the tree, the tenant-level integration under Connections → Integrations.
• Turn Inherit events from parent off and the card reveals that channel's own destination fields for this space. For Microsoft Teams that is a required Webhook field. Paste the URL and click Update.

Inheritance. Set a destination at the top of a branch and every space beneath it follows it. Turn Inherit events from parent off on a single room and only that room changes — everything above and below it is untouched.

📘

A separate Teams channel for every location

Because the destination belongs to the space, each location can notify its own Microsoft Teams channel. Create a Workflows webhook for each channel (see Microsoft Teams), turn off Inherit events from parent on that location, and paste its webhook into the Webhook field.

There is no limit on how many spaces can carry their own destination — tenants run this across several hundred locations today.

❗️

Requires a plan that includes Incident Routing

Per-space routing is available on Standard and above. If the Routing section is greyed out, check your plan under Settings → Plan & Billing, or contact support.

Access

From here, you can grant access to additional users or groups of users, to a particular space or across several spaces.

• Access granted here applies to the space, every device in it, and every space beneath it.
• A group only grants access where it is added to a space. Creating a group under Settings → Users & Groups and adding members does not, by itself, give those members access to anything.
• A user's effective access is the highest level they hold from anywhere — a direct grant on the space, any group with access to it, or a group with access to a space above it. Granting Admin here raises a user who is otherwise a viewer; setting a space or a group to View does not reduce someone who already holds Edit or Admin from elsewhere.
• Members of the tenant's administrators group have full access to every space and device. That is resolved before any space-level setting, so it cannot be reduced here.

See Access Management for the full access model, and the Users & Groups FAQ if a view-only user can still make changes.