Less admin, more innovation: how HASP transformed data access

Data research services exist to get the right data into the right researchers' hands, with the right checks in between, so projects can inform policy, strengthen public services and ultimately improve lives. But a surprising share of time can go on something else entirely: the administration of access and tracking usage. Answering "where's my data?" emails. Chasing missing details on a proposal. Setting up accounts on a ticketing system so that researchers can see their own tickets. Handling the same researcher's five requests as five separate pieces of work. Tracking what data has been requested and why. None of it is difficult, none of it is what the service is actually for, and yet when looked at as a whole, these tasks are an enormous time drain, not only creating extra work for the HASP team, but potentially providing a challenging user experience for researchers.

The Healthy and Sustainable Places Data Service (HASP), run from the University of Leeds as part of Smart Data Research UK, had a version of this problem. Its catalogue holds 33 datasets across three access tiers: open data anyone can use, safeguarded data that needs a project proposal and review, and controlled data with tighter conditions. The governance was already sound. Singular open data requests were released automatically, and requests involving safeguarded or controlled data went to HASP's team for approval. But the process around that governance was built on manual tickets and follow ups. Researchers had to create an account on the ticketing system to submit a request and to follow its progress, each dataset was a separate request, and a researcher working across several datasets ended up with several tickets, several threads and often, several sets of questions for HASP's team to answer. Tracking which data was being used and by whom to make any kind of meaningful inferences was a lengthy process.

Over the first half of 2026, HASP and MetadataWorks replaced that with a Project Access Management (PAM) layer on top of the existing data catalogue, to provide a streamlined user experience and cut down on admin time. It went live in July. The level of governance is unchanged. What changed is the unit of work: the process is now organised around the researcher's project, not around individual requests and automatically connects to HASP’s existing email marketing platform, allowing the team to tailor communications to the users interests – an improved experience both for researchers and for HASP.

What’s Changed…

One application instead of many

As a researcher browses the catalogue, they add datasets to a basket, and for each one they say what they want it for, over what time period and for which geography. When the basket is submitted it becomes one application. An application containing only open data is approved automatically, as before. An application containing any safeguarded or controlled data goes through HASP's approval stages.

For HASP's team, that is one review request instead of several. A researcher who needs one safeguarded dataset and four open ones now makes one application, so the team reads one proposal, asks its questions once and records one outcome. The per-dataset purpose, time period and geography make data minimisation real rather than aspirational, and they pre-populate the proposal form, so the team spends less time asking for information the researcher has already given.

Fewer questions, answered faster

Most of the admin in an access process is not the decision. It is the back-and-forth on the way to it. PAM is built to cut that down, making the user experience quicker and clearer. Reviewers attach a query to a specific field of the proposal rather than sending a general "please clarify" email; the researcher is able to see exactly which sections were queried, edits them directly, and resubmit with ease. Status changes generate a notification automatically, so nobody on HASP's team drafts a "your application has moved to review" email, and nobody fields a "where's my request?" one either. Adding a colleague after approval is a short change request rather than a new application, and the new team member receives their invitation automatically.

Researchers no longer touch a separate ticketing system at all. Everything happens on the user friendly HASP-branded site, which means HASP no longer has to support accounts on a tool that researchers only ever saw because the process needed them to.

A team that can see what it's running

Researchers register once, with a short form, and everything they do afterwards attaches to that one profile: the datasets they've downloaded, the projects they're on, the applications in progress, the service desk tickets they've raised. Researchers get a dashboard of their own applications and projects, which is where most of the "where's my request?" questions go to disappear. HASP's team get the mirror image: a view of every approved project and the researchers on it, plus an export of projects, the datasets they use and the users involved. HASP combines that export with their own data to build their reporting, including which datasets are most used, which is exactly the evidence a service needs when it decides where to invest its curation effort next.

Consent is handled as two separate questions. Service notifications are part of using the service; marketing consent is a distinct, optional choice, and only researchers who have given it are synchronised to HASP's Campaign Monitor audience. That gives HASP confidence in their communications list without anyone needing to maintain it by hand.

No dual running

A new process only saves time if it doesn't leave the team running the old one alongside it. Every application ever submitted through HASP's previous system was migrated into PAM: completed open data requests and approved projects as historical records, and around seventy in-flight applications as live records pre-filled with everything the applicant had already submitted, comments included. Each migrated project carries its original reference, so a researcher searching for the ID from a two-year-old email still finds their project and nobody at HASP has to go looking for it.

What it adds up to

In HASPs own words (Kiara Barker, Service Manager); ‘The new functionality allows users to request multiple datasets in one project proposal, streamlining the user experience. The user profiles and integration with our email marketing platform allow targeted communications tailored to researcher's interest, overall, the experience for both the researcher and the HASP team has significantly improved’.

The tiers, the checks and the approvals are exactly what they were, because they were already right. What HASP removed was everything around them: the duplicate applications, the status emails, the account admin, the hunting through threads. Time a small team was spending on the mechanics of access can now go on the things a data service exists to do — curating data, supporting researchers and growing the use of what it holds. And time researchers were spending waiting for approval and resubmitting tickets on a separate site can now go back into their core projects.