Skip to content
← All articles
Service

Service access: case sharing, holiday calendars and permission sets

Service access: case sharing, holiday calendars and permission sets

What this article covers Roles say what a person can do across the whole base. Four questions roles alone cannot answer live in Settings, Service access and administration: who else reaches one specific case, which days a specific queue does not work, how to grant one extra permission without inventing a role, and who authorized an integration.

Share one case with someone Open the case and use Share this case. Choose a person or a team, choose Read or Read and edit, write the reason and, when it makes sense, a date to end it.

  • Sharing does not change the owner and does not widen the role of anyone.
  • Sharing never grants delete or export. Someone invited to help solve a case was not authorized to destroy it or to take the data away.
  • An expired share stops granting access at the moment it expires, and the line stays in the history so you can still answer who had access in March.
  • Whoever shared can always revoke. Revoking someone else's share is a separate permission, given to the support manager.
  • Settings, Service access and administration, Case sharing lists every access opened outside the roles, so it also gets reviewed.

Holiday calendars per queue or region A calendar has a name, a region and its own holidays, and each queue follows one.

  • Holidays with the year left blank repeat every year. Holidays with a year happen only in that year, which is what moving dates need.
  • Calendar holidays are ADDED to the workspace holidays, never replace them.
  • A queue with no calendar of its own follows the default calendar.
  • The SLA of a case in the queue counts working minutes with that calendar, so a queue in one country stops carrying the days off of another.
  • You can paste a list you already have, one date per line. Lines we cannot read are shown back to you instead of being dropped in silence.

Permission sets A permission set is an additive role: it is added to the profile the person already has instead of replacing it.

  • Create the set, open its matrix in Roles and choose the cells it grants.
  • Give it to a person and the preview says exactly what it opens before you confirm.
  • Access is the union of everything the person holds, with the widest scope winning. Taking the set back returns them to their profile.
  • Who can what shows, per person, the roles they hold and the read scope for each service resource.

Integration governance The Integrations tab lists what is connected, which category it belongs to, whether it receives outside data through a webhook and whether a credential is stored. It never shows the credential or the configuration.

  • If your workspace has an approval policy of type integration_enable, connecting a new integration opens a request and waits for the chain.
  • One approval allows one connection. Turning an integration off is never blocked.
  • The request stores the provider name only. The credential keeps travelling through the encrypted path on the Integrations screen.

Storage per object There is no storage quota in this product, the brake is the spend cap. The Storage tab shows how much each object takes in files, so you know where to clean up. Older files that never recorded a size are counted apart, and the total says at least.

Open this article inside the system →

Read it and want to see it working?

The account is free and the whole manual is available inside the system, with an assistant that answers from this very content.

Create free account
Service access: case sharing, holiday calendars and permission sets Ā· Sellio