> For the complete documentation index, see [llms.txt](https://developer.vario-software.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.vario-software.de/app-store-guidelines/submission-resources/review-guide-template.md). # Review Guide Template Template for giving VARIO reviewers everything needed to install, configure, and test an app. Use this template to prepare the Review Guide for your App Store submission. The Review Guide should allow VARIO to install, configure, and test the app without undocumented assistance from the App Provider. Replace all placeholders with information about your app and remove sections that are not applicable. {% hint style="info" %} Keep the Review Guide practical. It is not intended to replace your customer documentation or technical documentation. Its purpose is to give the VARIO reviewer the shortest reliable path through the functionality that needs to be reviewed. {% endhint %} ### Review information #### App name **\[APP NAME]** #### App identifier **\[APP IDENTIFIER]** #### Version submitted for review **\[VERSION]** Example: > 1.0.0 #### App Provider **\[COMPANY NAME]** #### Review contact **Name:** \[NAME]\ **Email:** \[EMAIL]\ **Role:** \[ROLE] The review contact should be able to coordinate product, technical, and access-related questions during the review. *** ### What this app does Describe the primary purpose of the app in a few sentences. > **\[SHORT DESCRIPTION OF THE APP AND ITS PRIMARY USE CASE]** A reviewer should be able to understand: * what the app does; * which VARIO process it extends or connects; * which external system is involved, if any; * what the expected customer outcome is. #### Primary customer outcome > **\[DESCRIBE THE MAIN RESULT THE CUSTOMER ACHIEVES]** Example: > Marketplace orders are imported automatically into VARIO Cloud and created as sales orders. *** ### Review scope Describe the functionality included in this review. #### Included * **\[FUNCTIONALITY]** * **\[FUNCTIONALITY]** * **\[FUNCTIONALITY]** #### Not included List functionality that exists but is intentionally outside the submitted review version. * **\[FUNCTIONALITY — IF APPLICABLE]** * **\[FUNCTIONALITY — IF APPLICABLE]** If all available functionality is included, state: > All functionality available in this version is included in the review scope. {% hint style="warning" %} Functionality advertised as available in the App Store listing must be included in the review scope. {% endhint %} *** ### Review environment #### VARIO Cloud environment **URL:** \[VARIO CLOUD REVIEW ENVIRONMENT] **Tenant / environment name:** \[NAME] #### App environment **URL:** \[APP URL — IF APPLICABLE] The environment provided for review should represent the version intended for publication. #### Environment status Confirm that: * [ ] the submitted app version is deployed; * [ ] the environment is available during the review period; * [ ] required external services are connected or available; * [ ] suitable test data is available; * [ ] no developer workstation or temporary local environment is required. *** ### Review credentials List which accounts VARIO requires to perform the review. {% hint style="danger" %} Do not place passwords, API keys, tokens, client secrets, or other sensitive credentials directly in this Review Guide. Provide secrets separately using the secure transfer method agreed with VARIO. {% endhint %} #### VARIO user **Username / reference:** \[REVIEW USER] **Required role or permissions:** \[ROLE / PERMISSIONS] **Credentials provided via:** \[SECURE METHOD] #### External service account **Service:** \[SERVICE NAME] **Username / account reference:** \[ACCOUNT] **Credentials provided via:** \[SECURE METHOD] #### Additional account **System:** \[SYSTEM] **Account reference:** \[ACCOUNT] **Credentials provided via:** \[SECURE METHOD] If no additional credentials are required, state: > No additional credentials required. *** ### Prerequisites List everything that must be available before the review can begin. #### VARIO prerequisites * **\[PREREQUISITE]** * **\[PREREQUISITE]** Example: > The review user must have the app-specific `use-app` authorization. If there are no special prerequisites, state: > No additional VARIO prerequisites. #### External prerequisites * **\[PREREQUISITE]** * **\[PREREQUISITE]** Example: > The provided marketplace sandbox account must be active. #### Required test data Describe any data that should already exist before the reviewer starts. Example: > The VARIO tenant contains three demonstration articles with article numbers `TEST-001` to `TEST-003`. Your test data: > **\[DESCRIBE REQUIRED TEST DATA]** *** ### Installation Describe how VARIO should install the app for review. If installation follows the standard VARIO Cloud App process without additional steps, state this explicitly. #### Installation steps 1. **\[STEP 1]** 2. **\[STEP 2]** 3. **\[STEP 3 — IF REQUIRED]** #### Expected result After installation, the reviewer should see: > **\[DESCRIBE THE EXPECTED INSTALLATION STATE]** Example: > The app appears in the VARIO Cloud navigation and opens the initial connection page. #### Additional configuration required **\[YES / NO]** If yes, continue with the configuration section below. *** ### Initial configuration Describe only the configuration required before the primary workflow can be tested. #### Configuration steps 1. Open **\[LOCATION IN APP]**. 2. **\[CONFIGURATION STEP]** 3. **\[CONFIGURATION STEP]** 4. Save the configuration. #### Expected result > **\[DESCRIBE HOW THE REVIEWER CAN VERIFY THAT CONFIGURATION WAS SUCCESSFUL]** Example: > The marketplace account is displayed as **Connected** and order import can be enabled. *** ### Primary review scenario This is the most important part of the Review Guide. Describe the complete workflow that represents the app's primary App Store use case. {% hint style="success" %} A good primary review scenario starts with a known state, describes an intentional action, and ends with a result that VARIO can verify. {% endhint %} #### Scenario **\[NAME OF PRIMARY SCENARIO]** #### Starting state Before starting: * **\[REQUIRED STATE]** * **\[REQUIRED STATE]** * **\[REQUIRED STATE]** #### Steps 1. **\[ACTION]** 2. **\[ACTION]** 3. **\[ACTION]** 4. **\[ACTION]** 5. **\[ACTION]** 6. **\[ACTION — IF APPLICABLE]** #### Expected result After completing the scenario: * **\[EXPECTED RESULT]** * **\[EXPECTED RESULT]** * **\[EXPECTED RESULT]** #### How to verify the result Explain exactly where the reviewer should look. > **\[DESCRIBE HOW THE RESULT CAN BE VERIFIED IN VARIO AND/OR THE EXTERNAL SYSTEM]** Example: > Open **Sales → Orders** in VARIO Cloud. A new sales order with the external marketplace order number should be visible. The corresponding entry in the app's synchronization history should show the status **Completed**. *** ### Secondary review scenarios Add only scenarios that represent important functionality beyond the primary workflow. #### Scenario 2 — \[NAME] **Purpose:** > \[WHAT THIS SCENARIO DEMONSTRATES] **Steps:** 1. \[STEP] 2. \[STEP] 3. \[STEP] **Expected result:** > \[EXPECTED RESULT] #### Scenario 3 — \[NAME] **Purpose:** > \[WHAT THIS SCENARIO DEMONSTRATES] **Steps:** 1. \[STEP] 2. \[STEP] 3. \[STEP] **Expected result:** > \[EXPECTED RESULT] Delete unused scenarios. *** ### VARIO permissions List every VARIO permission requested by the submitted app version. | Permission | Used for | | ----------------- | -------------------- | | `[RESOURCE:VERB]` | \[FUNCTIONAL REASON] | | `[RESOURCE:VERB]` | \[FUNCTIONAL REASON] | | `[RESOURCE:VERB]` | \[FUNCTIONAL REASON] | Example: | Permission | Used for | | ----------------- | ------------------------------------------------------------------------------------------ | | `account:read` | Reads customer information required to create shipments in the connected shipping service. | | `document:create` | Creates the VARIO business document generated by the app workflow. | If a permission applies only to optional functionality, identify this in the explanation. *** ### App-specific authorization List the app-specific permissions or authorization verbs relevant to the review. | Authorization | Purpose | | ----------------- | ---------- | | `[AUTHORIZATION]` | \[PURPOSE] | | `[AUTHORIZATION]` | \[PURPOSE] | Explain which review user has which authorization where this affects the test scenario. If the app does not define app-specific authorization, state: > No additional app-specific authorization. *** ### Data flow Briefly describe the data exchanged by the primary workflow. #### VARIO → App / external system > **\[DESCRIBE RELEVANT DATA]** Example: > Article number, description, quantity, weight, and shipping address are transmitted to the shipping provider when a shipment is created. #### External system → VARIO > **\[DESCRIBE RELEVANT DATA]** Example: > Shipment number, carrier, label information, and tracking number are returned to VARIO. #### No bidirectional synchronization If the app is one-directional, state this clearly. Example: > Data is transferred only from VARIO Cloud to the external service. No business data is written back to VARIO. *** ### External systems List external systems involved in the reviewed workflow. #### \[SYSTEM NAME] **Purpose:** > \[HOW THE SYSTEM IS USED] **Environment:** > \[SANDBOX / TEST / PRODUCTION-LIKE REVIEW ENVIRONMENT] **Relevant limitation:** > \[LIMITATION OR "NONE"] Add further systems as required. *** ### Background processing Complete this section if the app uses Webhooks, queues, scheduled processing, imports, or other asynchronous processes. #### Process **\[PROCESS NAME]** #### Trigger **\[WEBHOOK / SCHEDULE / USER ACTION / OTHER]** #### Expected processing time **\[APPROXIMATE EXPECTATION]** Avoid promising a fixed processing time unless this is actually guaranteed. #### Where to view the status > **\[LOCATION]** #### Possible statuses * **\[STATUS]** * **\[STATUS]** * **\[STATUS]** Example: * Queued * Processing * Completed * Failed #### Retry behavior > **\[EXPLAIN WHETHER AND HOW FAILED PROCESSING CAN BE RETRIED]** *** ### Error scenario Provide at least one relevant error or validation scenario if errors are important to the primary workflow. #### Scenario **\[ERROR SCENARIO]** #### How to reproduce 1. **\[STEP]** 2. **\[STEP]** 3. **\[STEP]** #### Expected behavior > **\[DESCRIBE THE EXPECTED ERROR MESSAGE OR STATUS]** #### Recovery > **\[DESCRIBE HOW THE USER CORRECTS OR RETRIES THE OPERATION]** Example: > Remove the invalid country code from the test address, correct the address in the external system, and select **Retry** in the app's processing history. *** ### Duplicate and retry scenario Complete this section where the app processes Webhooks, imports, payments, documents, orders, or other operations where duplicate execution could create business problems. #### Scenario > **\[DESCRIBE HOW THE SAME EVENT OR OPERATION CAN BE REPEATED]** #### Expected behavior > **\[DESCRIBE HOW THE APP PREVENTS AN UNINTENDED DUPLICATE]** Example: > Triggering the same marketplace order import again must not create a second VARIO sales order. The existing mapping is detected and the order remains linked to the original VARIO document. If this scenario is not relevant, state: > Not applicable. *** ### Installation retry If relevant, describe how VARIO can verify that installation can safely be called more than once. #### Test 1. **\[STEP]** 2. **\[STEP]** 3. **\[STEP]** #### Expected result > **\[EXPECTED RESULT]** The repeated installation must not unintentionally create duplicate configuration, Webhooks, scheduled jobs, or other tenant-specific objects. *** ### Uninstallation Describe how the reviewer can uninstall the app. #### Steps 1. **\[STEP]** 2. **\[STEP]** 3. **\[STEP — IF APPLICABLE]** #### Expected result After uninstallation: * **\[EXPECTED RESULT]** * **\[EXPECTED RESULT]** * **\[EXPECTED RESULT]** Where relevant, confirm that: * automated synchronization stops; * Webhook processing stops; * tenant-specific credentials are no longer used; * previously created VARIO business data remains in the expected state. #### Data retained after uninstallation > **\[DESCRIBE RELEVANT APP DATA THAT REMAINS, OR STATE "NONE"]** This description should be consistent with the app's documentation and privacy information. *** ### Reinstallation Complete this section if reinstallation is relevant to the app. #### Steps 1. **\[STEP]** 2. **\[STEP]** 3. **\[STEP]** #### Expected result > **\[DESCRIBE EXPECTED REINSTALLATION STATE]** The reviewer should be able to verify that obsolete credentials, configuration, or background processes from the previous installation do not cause unintended behavior. *** ### Known limitations List relevant limitations of the submitted version. * **\[LIMITATION]** * **\[LIMITATION]** * **\[LIMITATION]** These limitations must be consistent with the App Store listing and customer documentation. If there are no material known limitations, state: > No additional material limitations relevant to this review. *** ### Special security or privacy notes Use this section only where VARIO needs additional context to understand the reviewed architecture. Examples may include: * unusual authentication behavior; * storage of customer data outside VARIO Cloud; * an external data-processing service; * a security-relevant configuration; * special tenant separation behavior. #### Note > **\[DESCRIPTION]** Do not include credentials or secrets. If there are no special considerations, state: > None. *** ### App Store listing differences Confirm that the review version corresponds to the submitted App Store listing. * [ ] App functionality matches the listing. * [ ] Prerequisites match the listing. * [ ] Supported systems match the listing. * [ ] Limitations match the listing. * [ ] Screenshots show the submitted version. * [ ] Documentation describes the submitted version. If there is an intentional difference, explain it: > **\[EXPLANATION OR "NONE"]** *** ### Additional review notes Provide anything else VARIO should know before starting the review. > **\[NOTES]** If there are no additional notes, state: > None. *** ### Re-review information Complete this section only when submitting an update to an already approved Public App. #### Previously approved version **\[VERSION]** #### New version **\[VERSION]** #### Change summary * **\[CHANGE]** * **\[CHANGE]** * **\[CHANGE]** #### Permissions changed **\[YES / NO]** If yes: > **\[DESCRIBE CHANGES]** #### Data processing changed **\[YES / NO]** If yes: > **\[DESCRIBE CHANGES]** #### External services changed **\[YES / NO]** If yes: > **\[DESCRIBE CHANGES]** #### Installation or migration behavior changed **\[YES / NO]** If yes: > **\[DESCRIBE CHANGES]** #### Areas requested for re-review > **\[DESCRIBE THE CHANGED FUNCTIONALITY VARIO SHOULD REVIEW]** *** ### Final Review Guide check Before submitting this guide, confirm that: * [ ] the app version is correct; * [ ] the review environment contains the submitted version; * [ ] all required accounts are available; * [ ] credentials have been provided separately and securely; * [ ] prerequisites are complete; * [ ] the primary review scenario can be completed from start to finish; * [ ] expected results can be verified clearly; * [ ] requested VARIO permissions are explained; * [ ] relevant external systems are available; * [ ] important error scenarios are documented; * [ ] known limitations are disclosed; * [ ] uninstallation can be tested; * [ ] the Review Guide matches the App Store listing and documentation. {% hint style="success" %} The Review Guide is ready when another person who has never seen the app can follow it from installation to the primary customer result without needing undocumented instructions from the developer. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://developer.vario-software.de/app-store-guidelines/submission-resources/review-guide-template.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.