Managed workspaces are a special kind of Ardoq workspace designed to keep your Ardoq data in sync with third-party applications.

They are set up as part of an integration and enable Ardoq administrators to:

Let’s look at each one in turn:

When you integrate data from a third-party application into Ardoq, it - and not Ardoq - is the master or lead source of that data. Data changes should be made in the third-party application and only mirrored in Ardoq.

For example, if you populate your Ardoq application workspace from ServiceNow, new applications along with their properties should be created in ServiceNow and loaded into Ardoq via the integration.

And once in Ardoq, you don’t want anybody changing those applications’ properties. So if an application has its Service Level set to ‘Gold’ in ServiceNow, this should not be overwritten in Ardoq.

However, it isn’t always the case that the third-party application is the master for all a component’s properties.

For example, while the application may be created in ServiceNow by the IT Operations team, some of its properties may be maintained by other teams: Its Strategic Rating may be determined by the Enterprise Architects, while its Risk Rating is decided by CISO.

So you may need to augment your component with extra properties not maintained in the master source, while at the same time ensuring that those properties are not modified.

Managed workspaces give you that ability. In a Managed workspace any property mapped from an integration will be read-only by default, but Ardoq administrators can also add additional editable properties directly in Ardoq.

This gives field-level master data with full governance control.

The second issue when integrating with third-party applications is managing the lifecycle of components across two applications.

For example, if a server is added to your cloud account, or a user added to your SSO solution, then it should be automatically added into an Ardoq workspace.

But if that server is deleted, or the user leaves the organization and is removed from SSO, it is not always the case that this information will be passed through on the integration.

Even if it is, you don’t always want to delete components from an Ardoq workspace just because they have been deleted from the source. Ardoq administrators may wish to retain components for audit purposes or to enable historical analysis.

Managed workspaces make managing component lifecycles across applications easier by identifying where a component is present on the source (a ‘linked component’) where it was present on the source but is no longer found, and where it has never been present on the source (i.e. it was created directly in Ardoq).

This enables the Ardoq administrator to identify where components have been dropped from the master source, whilst still allowing them to manage the deletion process within Ardoq.

For example, when an application owner leaves the organization, they can reallocate their applications before dropping the owner from Ardoq.

Setting up a Managed workspace is part of setting up an integration (more specifically, it is created when an integration schedule is set up).

Currently, the following integrations create a Managed workspace when a schedule is created:

If a Managed workspace- compatible integration is scheduled, the target workspace will be marked as managed and the fields mapped in the integration marked as read-only.

When you open a Managed workspace from Ardoq’s home page, you will be shown this alert:

When the Managed workspace is open you will see it labeled as “Externally managed” to make it clear that a scheduled integration is updating it.

Additionally, components in the Managed workspace may be marked icons to indicate their status. If a component is marked with the 'link' icon...

...it means it was created by a scheduled integration. If you delete a component marked with this icon you will see this message:

If a component is marked with the 'broken link' icon...

...it means the component was created by a scheduled integration but was not present during the last import. This means the component has probably been deleted from the master source.

A component with no icon means it was not created by the integration but directly in Ardoq.

Any field mappings from the third-party application will also be marked as read-only to indicate that they will be kept up to date by the integration.

Here’s an example of a Managed workspace with locked fields:

Only managed components (and references) will have locked fields. This means that it will be possible to edit fields for components that are no longer managed or that were not created via the scheduled integration. This can be seen for the two unmanaged components in the example above (“Deleted user” and “User that was not imported”).

Read-only fields are designated by the integration. Note that the fields mapped in the integration below are the same ones locked from editing in the example above:

👉 Have any questions? Please send an email to support@ardoq.com or reach out in the in-App chat, where our support team will be happy to help!