Modularise app logic - currentHost, subscribed modules, and endpoint URLs

A global app can be deployed on multiple SKUs. A SKU can contain multiple products. A Freshworks customer (your app user) can subscribe to specific SKU plans. These plans determine the access that the customer has to the various products in the SKU. The app users’ SKU subscription determines the products (and therefore the modules) that the app user has access (subscription) to. These modules are the subscribed_modules of the app user. In our back-end system, we identify module subscriptions based on the host on which the app is installed. We call this host currentHost.

Consider the scenario shown in the following image.

  • Customer2 has subscribed to a plan of SKU2 that offers access to all three products - Image of FreshchatImage of Freshsales ClassicImage of Freshcaller - in SKU2.
  • Customer3 has subscribed to a plan of SKU2 that offers access only to Image of Freshchat.
  • module_b is a functional unit of Image of Freshchat
  • module_c is a functional unit of Image of Freshsales Classic

Image of app deployment based on SKU subscriptionApp deployment based on SKU subscription

In this case, Customer2’s subscribed products are Image of FreshchatImage of Freshsales ClassicImage of Freshcaller. As a result, inherently Customer2 has subscribed to both module_b and module_c. When the app is deployed on Customer2’s product account (currentHost), the subscribed_modules identified in the backend are module_b and module_c.

Similarly, Customer3’s subscribed product is Image of Freshchat. As a result, inherently Customer2 has subscribed only to module_b . When the app is deployed on Customer3’s product account (currentHost), the subscribed_modules identified in the backend is module_b.

You can implement module-specific app logic for your app. We provide mechanisms for your app to retrieve the subscribed_modules from our back-end and run the corresponding app logic, at installation and at run-time. In the case of the previous example, your app logic can be modularised as module_b specific app logic and module_c specific app logic. At run-time an app deployed on Customer2’s account runs module_b and module_c specific app logic. At run-time, an app deployed on Customer3’s account only runs module_b specific app logic.

At times, your app logic can involve calling APIs to access the resources of the product on which the app is deployed. To enable your app to place an API call, you would require the URLs or endpoints to the product resources. We provide mechanisms for your app to retrieve these endpoint URLs.

FAQs

When building a front-end app, how can you retrieve the subscribed modules and endpoint URLs?

We offer the currentHost data method, to retrieve this information.

When building a serverless app, how can you retrieve the subscribed modules and endpoint URLs?

As part of the serverless event payload that is passed to the app, we send this information.

In your app, how can you place a templated request method call to the host Freshworks’ product where the app is installed?

As part of the app logic, when constructing the request template, use the currentHost template substitution.

When building an app settings page by using iparams.json, how can you specify module-specific installation parameters?

In iparams.json, tie the iparams to the modules by using the iparams.json > modules attribute.

When the app is installed, from the currentHost, the modules that the app user has subscribed to are retrieved in the backend. From iparams.json, all iparams without any module associated are displayed on the app Settings page. If an iparam has a module associated with it and if the app user has subscribed to that module, the iparam is displayed on the app Settings page.

When building a custom installation page by using iparams.html, how can you specify module-specific installation parameters?

  1. In iparams.html, include the currentHost data method to retrieve the subscribed modules and render module-specific iparams.
  2. In iparams.js, implement the module-specific logic.

When the app is installed, based on the currentHost, the modules that the app user has subscribed to are retrieved in the backend. From iparams.html, all iparams without any module specificity are displayed on the custom installation page. If an iparam is tied to a module and if the app user has subscribed to that module, the iparam is displayed on the custom installation page.