This page will give you an overview of the criteria we will check during the custom report review process. Below are the steps that we follow when reviewing a report for publication. As a general rule, the entire review process should not take longer than 10 business days, but can occasionally take longer, depending on the complexity and quantity of current review requests. If minor changes to an already existing report are to be reviewed, please let us know, so we can expedite the process.

Report Metadata Review

For the reporting metadata, the following points are required:


  1. Screenshots should be exactly 1280px x 800px with a maximum size of 1 MB.

  2. Multiple screenshot should show a clear progression through the report

  3. Screenshot should always show the full browser and not be cut.


Thumbnails should be exactly 1280px x 800px with a maximum size of 400KB.


  1. A report should always have a concise summary of its use cases, functionality, used Fact Sheet types and tags
  2. Is the report changing existing data (e.g. mutation)?


  1. Are configured data fields required

  2. Are specific tags required

  3. Which data is required for the report to work

Technical Review


Dependencies will be audited with npm audit more info, vulnerable dependencies will be rejected. Please provide information about cases, where changing the used library is not viable.

Code readability and error handling

  1. The code should be commented extensively

  2. Javascript Promises should include an error handler

  3. Traversing JSON response objects should include a null-checker

API Calls

  1. API calls and especially mutations need to be clearly visible and must not obfuscate what data is used in which way

  2. Calls to an external API, other than an LeanIX API, are not allowed. Sending data to external systems is strictly forbidden. Get in contact with support, if your use case requires this functionality.


The code needs a readme file, where, as a minimum all steps required for installation are listed. If dependencies with special installation requirements are used, those will have to be listed as well.

Recreating existing functionality

Framework functionality should be used as much as possible and not be re-created, refer to for an overview.

Commercial Dependencies

The licence status of all used dependencies will be checked.
Commercial dependencies should be clearly marked in the documentation, and confirmation of eligibility will be requested.

Functional Review


Report must run out of the box without producing any unhandled errors.

Look and feel

Reports should be using the same look and feel as default reports:

  • Filtering
  • Configuration
  • Design

Use cases

Reports need to have a clear use case.