On Sunday, September 3rd, we will release the first phase in a series of major product improvements: making all Ardoq objects global. This release will enable global fields. Read on for an explanation of what that means, why it’s a big improvement, and what to expect with the change!

What’s changing

Currently, component and reference fields are unique per workspace. If, for example, you have a “Cost” field for a component in one workspace, and another identical “Cost” field in another workspace, they are stored as different fields.

The change we’re making will make fields global across workspaces; the “Cost” field would be the same field wherever you use it in Ardoq, in any workspace.

To enable this change, we need to transition all existing fields in Ardoq to be global within each organization. The migration process will be automatic, and your data will not be changed.

What’s so great about global fields?

We encourage users to break their data up into multiple workspaces, then connect those workspaces with references—domain-specific workspaces make it easier to split up responsibilities and manage complexity. But there is an inherent drawback to this approach: each workspace can create unique definitions for objects.

One workspace could define “Risk” as a range from 0-10, and another as Low/Med/High. One could have a “Release Date” field with quarterly increments, the other with daily. Can you imagine trying to perform analysis across those two workspaces?

Our goal with Ardoq is to unify documentation across organizations – and global fields is a huge part of that. It’s the first step in a process to make most elements in Ardoq global (fields, component types, reference types, and tags).

Here are a few of the benefits of global fields:

  1. A unified language for your organization: No more varying definitions of what “Cost”, “Risk”, or “Criticality” mean. Having a unified language makes it easier to compare and connect data from different domains.
  2. Apply filters across workspaces: Instead of creating 3 filters for 3 open workspaces, all with their own definition of “Risk”, global fields enables you to create one filter for all of them using the global definition.
  3. Analytics: Once Ardoq knows that “Risk” is a number everywhere, you can use the Advanced Search module to scan the entire organization for, e.g., components with a Risk > 4 and a release date before November 1.
  4. Search for field values: This change also allows us to expose field values in search results, making it easier to locate data.

Potential issues

We’re confident that the changes will not be visible to most users, but there is always the possibility that there are edge cases we haven’t foreseen. To reiterate: your data is safe and we will promptly fix any issues that arise.

There may be some issues with saved filters that use fields that were migrated. Please let us know if you have trouble with this.

Also, the URLs for filters that use migrated fields will change, so if you have bookmarked or shared any, the links will no longer work. Please create saved filters for any that you would like to preserve.

In general, if you notice anything that looks wrong, please contact us. Your data is backed up, so we can roll back any changes that cause issues.

Other changes

There are a few other changes accompanying this transition that you may notice.

Inability to modify active fields

Once a global field is in use, making changes to its settings would affect all users and components or references that use it. For this reason, we’ve had to restrict some field actions:

  • Changing field name
  • Changing field type
  • Removing list options

We intend to allow administrators to perform these actions in the future, but if this causes you frustration, we can make these types of changes for you—just contact us to let us know.

For API users

API users can no longer view the API attribute name of fields within the app, but can still do so using the API.