Overview

Workbench dashboard is the user interface, exposed on the Root management dashboard, where you can manage and view important information related to the product modules enabled for your organisation.

To access Workbench dashboard, you need to log into the Root management dashboard and open the Workbench Settings by clicking on the handyman tools icon on the bottom left. You will then be able to select "Product modules".

Workbench dashboard allows you to access two categories of information related to your product module:

• Product module metadata - Includes information on the current published and latest draft version of a product module, as well as the product module's readme file.
• Product module execution logs - These execution logs are generated when your product module code is run by the Root platform, which happens each time one of the functions defined in your product module code is executed..

Before we cover these two topics, we will first explore key concepts related to product module versions and testing.

Key concepts

Sandbox vs. production environment

Sandbox mode is used for testing on Root. You can safely experiment in sandbox mode without worrying about breaking anything or creating unintended side-effects. When you are in sandbox mode, you cannot issue "real" policies. No billing or collections will run for policies issued in sandbox mode.

However, issuing and updating sandbox policies do trigger email notifications to policyholders. So you should ensure that you don't use real customer email addresses when creating policyholders in sandbox mode.

You organisation's sandbox data can be flushed at any time from the dashboard. You should therefore not rely on sandbox data persisting on the platform over time.

On the Root management dashboard, you will know you are in sandbox mode when you see a yellow banner across the top of the screen. When interacting with the Root API endpoints, you can test in sandbox mode by using the base URL https://sandbox.root.co.za/v1, instead of the production URL https://api.root.co.za/v1.

While you are still in the build and test phase, your product module will typically be enabled only in the sandbox environment. When you are ready to start issuing real policies, contact the Root team to enable your product module in production.

Live vs. draft version of a product module definition

Every time a new change is pushed to a product module, this creates a new minor version of the product module definition. For example, version 1.2 will be created from version 1.1.

When draft changes to a product module are deployed to live, this creates a new major version of a product module. For example, version 2.0 will be created from version 1.2. The live version of a product module is typically the version currently used in production, while the latest draft version will contain pending changes before they are deployed to live.

The draft product module definition allows you to test any changes before they are deployed to live. You can do this by selecting "Latest draft" when you issue a new policy on the dashboard. When issuing policies via the API, you can use the draft product module definition by adding ?version=draft to the URL when getting a quote.

📘

The quote determines the product module definition associated with the policy

The ?version=draft parameter can only be used on the endpoint to get a quote - not on the endpoints to create an application or issue a policy. The quote determines which product module definition (live or draft) will be associated with the application and the policy.

In sandbox mode, both the live and latest draft version of a product module can be used to issue policies. By contrast, when issuing real policies in the production environment, only the live version of a product module can be used.

Product module metadata

Under "Product modules" you will find a list of all the product modules that are enabled for your organisation. Greyed out product modules indicate that they are not owned by your organisation.

The following information is shown for each product module.

If a product module is owned by your organisation, you can click on it for more detailed information, as shown below. This view includes information on the latest draft version of the product module, and allows you to view the product module's readme file. The readme can be configured using the Workbench CLI tool.

Execution logs

📘

Execution logs are only available in the product module's owner organisation

Each product module has a single owner organisation. The execution logs for a product module can only be viewed in the owner organisation of that product module.

The Root platform executes your product module code in order to call the product-specific functions you have defined. Calls to these function (or "hooks") can be triggered by one of the following types of events:

• API calls - For example, a call to the getting a quote endpoint will execute the functions validateQuoteRequest() and getQuote() in the product module code.
• Lifecycle events - For example, when a policy lapses, the afterPolicyLapsed() function will be executed (if it is defined).
• Scheduled functions - For example, if you have set up a function called handlePolicyAnniversary() to run every day.

Each time your product module code is executed to complete one of these function calls, a new execution log will be created.

You can filter execution logs for your product module by the policy ID, the function name and the execution status. Each execution can have one of three statuses: complete, in progress or failed.

Clicking on an execution entry will provide additional information, as shown below.

In case of a failed execution, a log will be displayed with the relevant error message, as shown below. These logs will also display any console.log() statements in your product module code.