Skip to main content
Two settings define how your tenant behaves for everyone on it: the shared timezone and the chat spaces runs report to. Neither takes long to configure — but getting both right before your first automated run saves your team from reading timestamps in the wrong zone and having to open the app to find out whether a sync failed.
Confirm the active tenant before saving. Tenant settings apply to the selected tenant, not every tenant you can access.

​
Before you start

Confirm:
  • You are signed in as a Tenant Admin for the tenant you want to manage.
  • The active tenant shown in Open User Settings is correct.
  • The tenant timezone is known.
  • A Google Chat incoming webhook is available for each space you intend to register.

​
What Tenant Settings controls

​
Steps

1

Confirm the tenant context

Open Ask Darpan. Search for Open User Settings.In Tenant Context, confirm the active tenant. If the wrong tenant is active, switch before continuing.
2

Open Tenant Settings

Open Ask Darpan again. Search for Open Tenant Settings and open the result.
3

Set the timezone

In Localization, choose Timezone.Select the timezone for the tenant and save. Use the timezone that operators expect for schedules, date windows, and review timestamps.This is the tenant default, not a hard rule. Anyone can set a personal timezone in User Settings that overrides it for their own view — see Timezones and how dates resolve below.
4

Register chat spaces

In Operations, choose Notifications.Add one entry per destination Google Chat space: a name that is unique within the tenant, and the space’s incoming webhook URL. Darpan validates the URL on save and stores it encrypted — saved spaces show their name and status, never the full URL.Automations link to a space, and individual users pick one of these spaces as their personal default. For the end-to-end alert flow, see Run-completion alerts.
5

Verify the change

Return to Open Tenant Settings and confirm the timezone and the registered spaces. For notification changes, run a small saved reconciliation or automation test when the team needs proof that messages are delivered.

​
Timezones and how dates resolve

Darpan resolves the timezone it displays and calculates in from the first of these that is set:
  1. The signed-in user’s preferred timezone, from User Settings.
  2. The tenant timezone, from Tenant Settings.
  3. The browser’s own timezone.
This affects more than formatting. Run date windows and API day ranges are anchored to midnight in the resolved timezone, so two people on the same tenant with different personal timezones can produce different day boundaries for the same saved run. Set the tenant timezone to the one your operations actually run on, and treat personal overrides as a convenience for people working elsewhere.

​
Share a source configuration with another tenant

An organisation running several tenants against one upstream system used to need the same credentials entered, rotated and audited separately in each. Sharing removes the duplication: one tenant owns the configuration, and named peer tenants may use it. Sharing applies to API source configurations. Ownership stays with one tenant — peers use the configuration, they do not take it over — and the credential itself is never exposed to a peer tenant, only the ability to run against it. Check the affected-tenant list before revoking. Revoking a configuration that another tenant’s runs depend on stops those runs from resolving their source.

​
Troubleshooting