Sandbox Workspace - Best Practices

Introduction

SAP LeanIX provides a standard production workspace to represent and manage your organization’s IT landscape and enterprise architecture data. Additionally, if needed, you have the option to add a sandbox workspace through a subscription extension.

The apparent added safety of testing configurations in a sandbox workspace comes at the expense of delay, added complexity, and duplicate effort. Hence, the recommended approach is just to rely on the production workspace and to have all your data and configuration active directly in the standard workspace. This keeps things simple, up-to-date, and agile.

However, there are valid and useful use cases for a sandbox workspace, and this guide outlines the best practices and scenarios where production and sandbox workspaces should be used.

📘

Note

If you need sandbox workspaces as an add-on, request them from your account excecutive.

Difference Between a Production and a Sandbox Workspace

A production workspace is the main SAP LeanIX environment where an organization stores and manages its real enterprise architecture data using a standard, predefined, yet configurable meta model.

A sandbox workspace, available through an additional subscription, is a separate environment used for proof-of-concept testing and activities that can have a large-scale impact on live data when applied in the production environment. A sandbox workspace is geared towards the core team, and the number of users who can access it is limited.

A sandbox workspace isn’t meant for user training, onboarding, or as a staging environment for configuration changes with scheduled synchronization of the live inventory data. Not all activities within the workspace, except for changes made to fact sheets, are recorded in the audit trail. Therefore, we do not support manually triggering the transfer of data and configuration changes between workspaces, although you can request to clone the production workspace to the sandbox through SAP LeanIX Support or SAP for Me.

Production Workspace Best Practices

Here are common scenarios and use cases that are recommended to be implemented directly in the production workspace, along with reasons why testing them in a sandbox is unnecessary:

• Onboarding and Training
  SAP LeanIX's user interface ensures that users are fully aware of any changes they make to fact sheet data. With clear Edit, Add, and Save buttons, it’s easy for users to see when changes are being applied. This helps prevent mistakes, especially by inexperienced users, when working with fact sheets, reports, diagrams, and other features. All changes are logged, visible to all users, and can be easily reviewed and reverted if needed.
  Introducing SAP LeanIX is more effective when using live data that users are already familiar with. If you want users new to SAP LeanIX to create new fact sheets and you doubt the initial data quality, a best practice is to leverage the draft status of fact sheets before they are included in reports after approval. Additionally, assigning at least one responsible user as a subscriber to each fact sheet offers several benefits, such as automatic notifications about changes, which helps maintain and monitor data quality. To learn more, see Quality Seal and Fact Sheet Subscription.
• Hiding Data
  Logically segregating sensitive data into different workspaces for security reasons is unnecessary, as virtual workspace configurations in the production workspace let you define which data is visible to different users while they all benefit from using the latest data in the same workspace. To learn more, see Virtual Workspaces.
• Meta Model Configuration
  SAP LeanIX provides the means to safely and efficiently apply meta model configurations on production workspaces and test them before exposing them to users. The visibility of fact sheets and their attributes can be limited to admin users before making them visible and editable for members. As a best practice, focus on a small scope of meta model changes and introduce them iteratively with a quick turnaround time of validating their value.
• New Dashboards, Diagrams, and Reports
  Access permissions for dashboards, diagrams, and reports can be set individually. These can remain private to the creator until they decide they are ready to be made visible to other users.
• Importing Fact Sheet Data Through Excel File
  When importing, the spreadsheet's content is validated before any data is added to or changed in the workspace. Before the users confirm the import, a summary of the changes is shown with details on fact sheet data (e.g., the number of new and changed fact sheets), ensuring accuracy and data integrity. For more, see Importing Fact Sheet Data Through Excel File.
• Surveys
  Surveys have a dedicated test run for creators to help survey creators check whether the content meets their intent.
• OData Integration
  Since this integration only reads data from a saved search in the workspace, configuring it directly in a live workspace poses no risk. It's helpful to create a dedicated saved search for the initial setup of the integration.
• Automations
  Automations are triggered by changes to fact sheet data, not existing data. Even if an automation is set up incorrectly, it won’t make irreversible changes. To minimize risks, start with small, controlled automation tasks, using tags to limit the scope. All automation actions are logged in the fact sheet audit trail for transparency.
  Automations are triggered by activities or changes to fact sheets, and not by existing data on the fact sheets. This means that even if an automation is set up incorrectly, it won’t make irreversible changes. General advice for automation is to start small by adding a condition based on a tag on a limited set of fact sheets to test the result. Changes from automations are visible in the audit log, showing them as performed by the technical user "LeanIX Default." For more, see Automations.

Sandbox Best Practices

A sandbox workspace is useful for testing large-scale changes to data without impacting the live workspace, ensuring safe implementation before applying changes to production. Some common use cases are:

• Initial Setup of Out-of-the-Box Integrations (e.g., SAP Signavio, ServiceNow, Collibra)
  These integrations may create dozens or even hundreds of fact sheets during the first sync, which can have a significant impact. It's recommended to set up and review the first sync in a sandbox before applying it to the live workspace.
• Building Custom Integrations
  Custom integrations using SAP LeanIX's public APIs can also create and alter large volumes of data. Hence, implement and test these integrations iteratively in a sandbox workspace before applying them to the live workspace.
• Initial Setup of Large-Scope Automations
  Automations that trigger changes to a large number of fact sheets (e.g., when many fact sheets are created simultaneously by integrations, and you have set fact sheet creation as a trigger for the automation) should be tested in a sandbox first. Since changes made by automation are only logged in the audit trail of each changed fact sheet, testing in a sandbox helps ensure the process runs smoothly before applying it to the live workspace.