Global Apps Framework (Beta): From Products to Modules

A Paradigm Shift in Freshworks App Development

Freshworks implemented a multi-product strategy in 2015, allowing developers to create apps for multiple products for their customers, solving business use cases in CX, IT, and CRM industries. The apps would see themselves being part of Freshworks products’ such as Freshdesk, Freshservice, and Freshsales.

A sample representation: Modules <> Offerings

Sooner, we discovered that apps are scoped to specific products, while use cases can span across products. Our solution to this problem is introducing Global Apps.

Learnings that led to the modular way

With platform version 3.0 this year, we launched a new paradigm to build apps on Freshworks — we are calling them modules.

For developers, a module is a shared unit in their apps that will allow publishing apps to one or more Freshworks product offerings with shared runtime.

For example, an app they build lists chat_conversation & deal as its modules, and our platform will render the apps for Freshsales and Freshsales Suite users, allowing them to expand their customer reach.

For customers, a global app can be played across their Freshworks products’ with modules the app has subscribed to.

As more developers publish global apps, customers will see the apps applying shared context across their products. This will enable cross-product usecases, such as an engineering ticket's priority, to be automatically set by linking it to an ongoing deal item (of Freshsales) and a support ticket (of Freshdesk) via an app.

Modular code interfaces

The development experience in building apps on the Freshworks platform becomes modular, starting with platform version 3.0. Consider a case when the app links tickets of Freshdesk and Freshservice to engineering tickets. This common theme of problems demands us to provide newer interfaces for the developers to equip their apps.

• Provide context at the runtime about the Freshworks’ product hosting the app. In this case, Freshdesk is where the app is installed.
• Empower developers with local tools for optimal UI and functionality by acknowledging the app’s role in module-based product installations during development.

Developers use the data method to gather contextual data on the current page viewed by the user. For example, a ticket ID of the ticket user viewing — Freshservice ticket? or a Freshdesk ticket?

The answer is both, depending on the runtime.

Without a modular approach,

const data = await client.data.get("loggedInUser");
// Get the Ticket ID from 'data'
linkTickets(id); // link with engineering tickets

With a modular approach,

// Know runtime — Freshservice, Freshdesk, or Freshsales?
const currentHost = await client.data.get("currentHost");

if (currentHost.subscribed_modules.includes("support_ticket")) {
    const requesterData = await client.data.get("requester");
    // link support ticket to engineering sprint
}

if (currentHost.subscribed_modules.includes("service_ticket")) {
    const = await client.data.get("user");
    // link service ticket to engineering sprint
}

Some new features include:

• A currentHost data method that lets the app context about its host for frontend features.
• The custom configuration page expands on _meta to store installation parameters.
• The iparams.json gets the modules property to map the store/retrieve operations.
• The changes to manifest and serverless components declare the context of the module and leverage functional reuse.

Our documentation is in the works and will soon be live on the website, along with code samples and tutorials.

Modular local development

Every app developer uses Freshworks’ CLI (FDK) to test and ensure bug-free shipping locally. This brings us to the challenge,

How can we enable developers to test their app on every product module subscribed by the app, instead of just one?

Developers typically create apps for a specific target audience but then expand to include additional modules and multiple Freshworks product users. Our focus shifted to creating a new setup page that enables developers to switch module runtime on demand while keeping customer views in mind.

Select a module from the manifest to simulate it on Freshdesk or Freshservice (in this case).

This feature allows developers to easily select the modules they want to test and simulate the tests on the target product. If developers subscribe to modules that support two products, they can test them separately on each product.

The Marketplace

When developers declare modules in their app, the app will be published to the marketplace and made available to all customers.

A screenshot of the selection available for customers to filter through apps

• All the supported apps will be listed in the product app gallery.
• All the apps can be filtered by module or product through the public app gallery.

The Global Apps Framework has been in a closed beta for a few months. It will soon be generally available in the upcoming months. If you want to be the first to know about this launch, sign up on the community and keep an eye out for our announcements.