In the Version 90 release (September 6, 2026) we are moving all Project Role definitions from URL level to Organization level.

When customers have more than a handful of URLs in TrialGrid, managing Project Role definitions and keeping them in sync across URLs becomes a real chore and makes license management difficult.

When Version 90 is released (and in prerelease) you will find that Project Roles appear at the Organization level. Along with that move, Role definitions become the responsibility of Organization superusers - they are the only users who can add, edit, delete or merge them.

Migration

Typically, the same Role name has been used in multiple URLs. Where these Role names match exactly and have exactly the same permissions, they become a single Role definition in the new listing.

However, if there is any difference between them then they arrive as separate definitions - the first keeps the plain name and the others have (1), (2) appended. You might also find that there are small variations in Role names and each of these variations has its own entry.

None of this changes what anyone can do. A user who was a Data Manager may now find they are a Data Manager (1), but with exactly the same permissions in exactly the same Projects. Nothing is merged for you, and nothing has to be merged at all - the cleanup below is yours to do at whatever pace suits you.

The listing also shows the license type each Role requires and how many users hold that Role across the whole organization. That is the picture which previously had to be assembled URL by URL, which is what made license management such hard work; it is now on a single page.

Merging Roles

You will likely want to clean up this list of roles by merging them. Select two or more roles and click the "Merge" button:

The dialog which appears will ask you what the new name of the merged Roles should be. You can re-use one of the names you are merging from or choose a new name. Note that the merged Role will get the superset of all permissions that any of the roles being merged had. So if you merge a role with permissions: Diagnostics and Create Draft with another that has Create Draft, Files and Wiki permissions you end up with a Role that has Diagnostics, Create Draft, Files and Wiki permissions. The permissions that will be set are shown in the dialog:

When you click the Merge Roles button all users who had the previous roles are re-pointed to the new Role and all Property Sheets, Actions and other role-specific settings are switched to the new Role definition.

Note that once merged it is not possible to reverse the process.

One thing merging will not do is give a group of users fewer permissions. Merging says "these two Roles are the same thing", and it always resolves to the superset. If you have a "Project Owner" Role carrying every permission and an "Administrator" Role carrying slightly fewer, merging the two will not bring your Project Owners down to Administrator level - it will raise every Administrator to every permission instead, with the licensing that follows from it. To get the result you were after, either move those users onto the Administrator Role and delete the "Project Owner" Role, or merge the two and then remove the unwanted permissions from the merged definition.

Before Version 90

There is no need to go hunting through your URLs ahead of the release, comparing Role definitions by hand. If you have twenty URLs that would be a considerable amount of work, and it is work the new listing does for you. The duplicates you see after the migration show the places where your definitions are different.

However, if two URLs both have a Role called "Data Manager" and the two definitions happen to carry the same permissions today, but they exist for different reasons and you expect them to diverge later, the migration will treat them as one Role and give you a single definition to edit. Renaming one of them before the Version 90 release - to "Data Manager (Training)", say - keeps them apart from the start, which is easier than separating them again afterward.

Summary

Defining Roles inside each URL made good sense when an organization had one or two of them, and most of our customers still work that way. Our largest do not: they run TrialGrid across hundreds of URLs, and one of them is maintaining more than a thousand Project Role definitions across those URLs. At that scale, keeping definitions aligned by hand stops being a minor chore and becomes a job of its own. This change moves Roles to the level at which they are now administered.

For customers with large numbers of URLs this change replaces a set of Role definitions that had to be kept in step by hand with one set that is defined, edited and licensed in a single place. You do not have to merge anything to get that - the definitions are consolidated whether you tidy the list or not - but merging is what turns a long list of near-duplicates into the handful of Roles your organization actually uses, each of them editable from one location.

Version 88 is a more focused release than usual, and deliberately so. We brought this release forward to the 21st of June to coincide with the rollout of Medidata's new Rave EDC release, 2026.2.0. That shortened timeframe, combined with a substantial body of behind-the-scenes work to update our automated testing framework for the EDC changes, means there are fewer headline features this time - but the ones that are here matter. Chief among them is an important change to how project access is managed: the Project Owner concept has been replaced by the more flexible Project Roles.

For more information see the release notes for Version 88.

Rave EDC 2026.2.0 Support

Medidata's Rave EDC 2026.2.0 release brings a range of changes, and much of our work this cycle went into making sure TrialGrid's automated testing framework runs cleanly against it. Automated Tests now fully support Rave EDC 2026.2.0, so your test execution stays in step with the latest EDC release from day one of its rollout - which is exactly why we aligned this release with Medidata's.

Project Roles Replace Project Owner

The single Project Owner has been removed in favor of managing users by Project Role. When creating a project you can now optionally assign a user to a Project Role directly from the Add Project page - the creator can assign the role to themselves or to any other URL user, without needing a separate "Manage Users" permission on the URL. Once created, any user with a Project Role that grants the "Assign Users" permission in that Project can add and remove members from the Project Team page, replacing the old shortcut that let owners manage their team without an explicit URL-level permission.

This is a migration as well as a feature: all existing Project Owner users have been moved to a Project Owner Role within their project, so nothing is lost in the transition. Because this is a significant change for some users, we have a dedicated post that walks through what it means for your projects. You can read it here: Retiring the Project Owner Role.

More Ways to Generate Test Cases

The Test Case generator has gained several new options that make it easier to broaden coverage without hand-writing extra scenarios. You can now repeat all scenarios across a range of folders, repeat them for record positions 1 and 2, add scenarios that specifically test blank values, and add scenarios that verify queries are closed after being opened. Together these let you exercise more of a study's behaviour - repeating data, log records, missing data and query lifecycle - from a single generation run.

Filtering and Custom Property Values

Object lists are easier to work through by assignment. You can now filter a list to show only Unassigned objects, and a new "Assigned to" dropdown lets you narrow the list to one or more specific users or roles - handy for seeing exactly what is on your plate or someone else's. And on a text Custom Property's value management page, you can now delete a value, which clears it on every record that uses it.

This post was auto-generated by a LLM.

In the Version 88 release (June 21, 2026) we are retiring the Project Owner role in favor of Project Roles.

If you are a Project Owner today, you do not need to do anything. We will automatically migrate you to a Role that has exactly the same permissions, so nothing changes about what you can do. The rest of this post explains the migration, how creating Projects changes, and - for those interested - why we made the change.

Migration

As part of the Version 88 release process we will find every Project that has a Project Owner assigned. In the URL for that Project we will create a Role called "Project Owner" with every permission set. If a URL already has a Role named "Project Owner", we will name the new Role "Project Owner (migrated)" instead. Every user who is a Project Owner will then be migrated to this new Role in their Project.

Organizations that have no users assigned as Project Owner in any of their Projects will not have this Role created.

Creating new Projects

In Version 88 the Project creation page looks a little different:

When you open the page it will automatically select your username and the "No role" option.

You must either select a Role for yourself (or another user), or set the Username option to "No user" and the Role to "No role".

Note that in a brand-new URL you will need to create at least one Role before this dropdown can be populated.

Why we are making this change

When we built TrialGrid in 2016, the first feature was running Diagnostics on Medidata Rave study builds. We wanted that to be fast: log in, create a Project, load an ALS, run Diagnostics - so the person who created a Project became its Project Owner, a role with every permission in that Project.

Ten years on, TrialGrid is much more than a study-build checker. Most work now happens through Project Roles: named sets of permissions, such as creating Drafts, editing objects, or applying labels. A Role lets Data Managers, Clinical Programmers and others work together in a Project, each with their own responsibilities. Against that, a single all-powerful Project Owner has become an awkward fit:

• There can be only one Project Owner. To share that ownership you have to use Project Roles anyway.
• Our larger customers do not use it, and many actively avoid it, preferring to manage every Project through defined Project Roles rather than a single owner.
• Licensing. A Project Owner has every permission, which makes them a Full License user. If your organization only licenses Rave Diagnostics, seeing Full License users in your user listings causes confusion and the worry that you are under-licensed.

All in all, TrialGrid's functionality and adoption have outgrown the original Project Owner concept. The migration we have put in place means every user keeps the same permissions they had before, now within a more streamlined structure.