What's the motivation for this feature?

By default, Skedda retains user data indefinitely in order to support the basic nature of our services, that is:

Users often want to create numerous bookings and visits on Skedda in an ongoing fashion, across the "lifetime" of their interaction with a venue and its spaces. Having a persisted "user account" allows them to avoid the burden of having to re-enter all their details for each new booking.
The administrators of the associated Skedda venue account often have an interest in keeping records of the bookings and visits that were made over time (including details of the people that held those bookings). If user data were always periodically deleted, it could violate the organization's record-keeping responsibilities.

In many cases, however, there's a bit more to it:

At some point, end users might cease creating new bookings and visits for the venue and its spaces. For example, an employee might leave a company, or a student might graduate.
The administrators of the associated Skedda account might not need long-term record-keeping. Perhaps just a few months of retention suffices.

In the age of the GDPR and similar data-protection legislation around the globe, it's extremely important to identify ways in which you can minimizing the storage of data (particularly personal data) that is no longer necessary to keep. In the GDPR this is referred to as the “Storage limitation" principle.

The motivation for this feature (and the closely-related Booking and Visit Data Retention feature) is therefore that it allows an organization to minimize the storage of data in its Skedda account by removing unneeded data. Configuring these features improves the organization's data-protection posture and helps it demonstrate that it's fulfilling its data-protection obligations.

Further motivation for this feature can be found in the direction of security. Organizations often have a security requirement to automate the provisioning and deprovisioning of associated accounts when users join and leave. Although Skedda's SSO integration provides auto provisioning, it doesn't support auto deprovisioning. This user-data retention feature can help solve this shortcoming because it too provides an automated mechanism to remove "inactive" user accounts. Indeed, this user-data retention period can in some sense be even more useful than traditional SSO-based deprovisioning, because it may well be the case that a user remains with the organization, but just doesn't need to use Skedda ongoing (e.g. they moved departments or went on multi-year parental leave). In such cases it's also useful to remove the user from Skedda, which this user-data retention period can provide.

Skedda strongly recommends that all venues/organizations think carefully about data-retention for their case, and configure the features that Skedda offers accordingly.

How does it work?

The idea is simple: When the feature is enabled and configured, regular users older than the chosen threshold are automatically deleted from Skedda if they have no remaining bookings or visits in the system (past or future).

Let's walk through an example:

Anna Admin from ABC Corp signs up for an organizational Skedda account to manage ABC's meeting rooms.
Anna configures the booking-and-visit-data retention feature to the tune of: "Automatically delete bookings and visits older than 6 months".
Anna then configures the user-data retention feature to the tune of: "Automatically delete users if they're older than 3 months and have no remaining bookings and visits in the system".
On January 1, ABC employee Randy Regular starts using ABC's Skedda account and creates his first booking for the same day. Randy is a brand new user (not older than 3 months) and has a booking in the system, so he's of course retained as a user.
On February 1, Randy leaves ABC for another job opportunity, having only created the one booking on January 1. Assuming a Skedda admin doesn't manually remove him from the Skedda users list, Randy's user account remains in the system (because Randy's Skedda user account is less than 3 months old and his January 1 booking is also still in the system).
On April 2, Randy's user account is now older than 3 months, but his booking from January 1 is still in the system (because it's retained for 6 months). Randy's user account continues to be retained in order to maintain the record-keeping integrity of his January 1 booking (i.e. so that Skedda admins know who created that booking).
On July 2, Randy's January 1 booking is automatically deleted from the system (because it's now older than 6 months). Some hours later, Skedda also deletes Randy's user account from the system, because he doesn't have any bookings left (past or future) and his user account is older than 3 months.

This example describes just one possible combination of the threshold values (6 months and 3 months) for booking-data and user-data retention. Skedda allows you to choose different values to suit your needs.

You might be asking yourself: Why bother with a user-age threshold at all (3 months in the example above)? Can't we just delete all users that have no bookings? Well, if the age of the user weren't considered, the issue is that a brand new user might be deleted immediately, before they've even had a chance to create their first booking (which would of course be very frustrating)!

How do I configure the feature?

Please think carefully about your data-retention goals before enabling this feature. You can use the example in the previous section to guide you. If you're unsure for any reason, reach out to the Skedda support team for consultation first.

A System Admin or Owner can opt in to enable and configure this feature (it is disabled by default).

The important first step is to configure your booking-and-visit-data retention period based on your needs. That setting controls how long bookings and visits "hang around" in your account after they've ended. The longer you retain bookings and visits, the longer it will take for the associated users ("holders" / "hosts", in the case of visits) of those bookings and visits to be removed from the system (because users are only removed when they have no remaining bookings/visits in the system).

Next, on the same Settings page (Settings > Data retention), under the "User Data Retention" heading, choose the "age" that users should have before even being considered for deletion.

The higher the age threshold, the longer the "guarantee" that a user account will be preserved in Skedda after it's created, regardless of whether or not they have any bookings or visits.

Finally, we recommend thinking about how you will communicate your configured auto-removal policy to your users on your side. In the spirit of transparency it's best to inform them of how their personal data will be retained. Users should generally welcome the efforts you're making to minimize the storage of their data, so we encourage you to present it in a very positive light!

If you never want users to be deleted, just choose the "Disabled" option (which is the default selection for all new Skedda venue/organizational accounts).

What if a user wants to "come back" after they've been deleted?

If the person wants to "come back", they're simply a "new user" and can follow your usual process for onboarding new users. Depending on your setup, this might involve sharing an invitation link with them, or (if you're using Single Sign-On) just having them navigate to the app again (they'll be auto-provisioned as a new user during SSO).

Note that, by definition, the user has no bookings or visits in the system when they're deleted, so there's no data that's lost "at scale" if they're deleted. In the "worst case", when they come back, they'd simply have to re-enter their basic details (name, email) and potentially set up their authentication credentials again (password or external login).

Further important notes

System-level users are never deleted, i.e. this feature only ever considers "regular/non-admin" users for deletion.
If a Skedda user account is associated with multiple venue accounts, the underlying platform-level user account is only removed once all associations with venue accounts have been removed. That is, if your organization has multiple Skedda venue accounts, you should configure this feature similarly on each one in order to ensure that user profiles are eventually removed from the platform level as well. Said otherwise for full clarify: Skedda's background worker task for removing user accounts will only delete the "association" of the user with a venue (and leave the underlying platform-level user account) if it detects that the association with a different venue account needs to remain.
Skedda's back-end systems process the deletion of user accounts in small periodic batches (currently on a two-hour schedule with executions at 00:40 UTC, 02:40 UTC, ..., 22:40 UTC). If you have a lot of "old" users without bookings/visits when you configure the feature, it may take a few executions of this background job before all the matching users to be removed.
The detailed logs describing when users are deleted are not visible to the system users of a venue at this time (System Admins, Owner). If you observe that the feature isn't behaving in the way you expect, you can reach out to Skedda's support team for clarification.
If, for any reason, you wish for the automated-deletion process to stop, simply choose the "Disabled" option in the feature configuration.
If you're enabling this feature on an existing account with a large number of existing users, consider starting with a conservative age threshold (i.e. 1 year) and then gradually working towards your target threshold over time. This approach might help to surface any incorrect assumptions you have made about your data-retention goals before too many users are affected.
Skedda's standard backup-retention policies (used for business continuity and disaster recovery) continue to apply. That is, even when a user is deleted from Skedda's "live" production data repository, backups of the information still exist for some days before being permanently irrecoverable.
Customizing the user-data retention based on user tags is not currently supported. That is, the feature applies to all non-admin users of the venue account.