Application Types

Applications are the main way to extend the functionality of CatalogIQ. Apps can plug into different parts of the platform.

Application Lifecycle

Applications follow a lifecycle within the CatalogIQ platform:

1. Installation: Admin uploads and installs the application package via CatalogIQ Admin
2. Loading: When requested, the application's HTML entry point is loaded into an iframe
3. Initialization: The application calls APIs like useApi().appLoaded() to signal it's ready
4. Active Phase: The application interacts with CatalogIQ via the JavaScript API
5. Cleanup:
   • Canvas hooks are explicitly destroyed when their canvas is closed
   • Canvas components can be rendered and destroyed multiple times as users navigate through the canvas
   • Other application types are typically unloaded when the user navigates away from their context

Different application types may have variations in this lifecycle based on their specific purpose and context.

Canvas / DSR components

Custom types of the canvas components. They can be displayed in the Pitchdecks and/or DSRs.

There can be multiple, independent instances of the Canvas apps on the same page. Each instance can have its own configuration and data. Canvas apps have their initial dimensions and can be resized by the user as well as resize themselves to fit their content.

When the user navigates through the canvas, the app can be rendered and destroyed multiple times. Updates to the canvas are propagated to the app through events.

Canvas apps can be headless, which means they do not have any visible UI in the presentation mode and are used to manipulate the canvas in the background. In such case they are however visible in canvas edit mode.

In the app.json manifest, canvas components are defined in the module.canvas section with properties like enabled, headless, auto_install, and dimension defaults.

Example use cases

• order capture,
• sales data charts,
• comparison table with other products.

Canvas hooks

Invisible components that can listen to events and manipulate the canvas.

Canvas hooks are not visible to the user and do not have any visible UI. They can listen to events and manipulate the canvas in the background. They are rendered once per canvas when it is opened and destroyed when the canvas is closed.

Example use cases

• fetch sales data from an external system and update the context,
• populate the canvas with products based on the account data coming from external system.

Sidebar applications

Applications that can be opened as a screens of the CatalogIQ.

Sidebar apps can provide additional functionality to the CatalogIQ platform that is independent of the Canvas and lives on its own.

Example use cases

• custom landing page for the sales reps,
• embedding internal company system in an iframe for easy access,
• detailed account information screen for an active meeting.

Admin applications

Applications that can be opened as a screens of CatalogIQ Admin. They can provide additional functionality to the Admin panel.

In the app.json manifest, admin applications are defined using the module.admin_instance property.

Example use cases

• data importer,
• custom settings,
• external system connection debugger,
• custom reports.

Interactive content

Interactive documents developed using html that can be displayed in the file viewer. They can contain animations, interactive elements, and videos. They are great when you need to present complex information in an engaging way that is not possible with static documents like PDFs and images.

Bear in mind that the interactive content is not editable by the user, it is only for presentation purposes. You should use it with caution as in many cases it is better to compose the content using the Canvas components.

Example use cases

• interactive presentation with animations and videos,
• interactive product brochure with dynamic price calculator.

Post-call forms

Custom form presented to the user after a call or meeting. It allows the user to capture and record detailed information about the meeting, such as notes, action items, follow-up tasks, and other relevant details. This ensures that all critical information is documented and can be referenced later.

Post-call forms can be provided by applications using the provide: ["postcall"] property in the app.json manifest. When a post-call application is available, it will be shown instead of the default post-call form.

Post-call forms have access to context data including:

• Meeting information (start/end time)
• Account information
• Contact information
• User information
• Canvas information used in the meeting

Example use cases

• Capturing meeting outcomes
• Recording follow-up actions
• Custom note-taking interfaces