RevOps byTom Schoorstra.
← All posts

By Tom SchoorstraPublished Updated

What are HubSpot app cards? A business guide

Bring useful context or a focused action onto a HubSpot record. How app cards differ from native cards, when custom work fits and what to check before building.

An app card adds an app's information or actions to a HubSpot record. It can put a related invoice status beside a deal or help a user start a process while reviewing that record.

I would start with the decision someone needs to make. If a small piece of context helps them make it, a card may be enough. The data source, permissions and maintenance still need an owner.

App cards and native record cards are different

HubSpot provides native record cards for properties, associations and other record information. Some can be configured in the record editor without building an app. HubSpot documents these options in Use cards on records.

An app card is supplied by an app. Modern app cards use React-based UI extensions and can display CRM or external data and support actions. Supported surfaces include record pages, preview panels and help desk sidebars, depending on the card's configuration. See the UI extensions overview.

A card in the right sidebar could use either modern or legacy technology. Its position alone does not identify the implementation.

Check existing options before building

Begin with the information already in HubSpot. A native property or association card may answer the question once the layout is configured.

Next, check your installed apps and suitable Marketplace apps. Confirm that the vendor supplies the card you need, which objects and locations it supports, and what account access or subscription it requires. Installation alone does not establish that the right users have the right card in their record view.

Custom development fits when a specific decision needs data or behavior those options do not provide. Agree who will maintain the app, its connected services and the record layout.

Scope one useful task

Possible tasks include checking an invoice status, showing a business-specific calculation or starting a delivery process in another system. Each needs its own data mapping and implementation; they are examples to scope rather than features every card includes.

My renewal-status card shows a focused example. It reads the linked license information and presents a status on the deal. It is read-only, with the lookup and hosting boundaries described in the case.

For a card that changes another system, define the allowed action, who can perform it and how success or failure is shown. I would make the read-only view useful before adding a write action.

Agree how the data and access work

A card's usefulness depends on correct record matching and a maintained source. Decide whether it reads stored CRM values, requests current information or uses a cached result. Show when information is unavailable or too old for the decision.

External data access needs a configured connection and backend. HubSpot's data-fetching guide covers permitted URLs and request handling. Apps using Sensitive Data scopes cannot use hubspot.fetch(); have the developer check the restrictions before promising an external lookup.

Test the intended users, permissions and record types. Include missing associations, source outages and repeated clicks on any action. Document credentials, hosting, monitoring and who handles a broken connection. A card displaying live information is still dependent on the systems behind it.

Check legacy cards separately

HubSpot's older announcement gives 31 October 2026 for the classic CRM card sunset. The current migration guide says removal from customer views is 2 November, with migration tooling available until 1 December. The tooling window does not extend the cards' visibility through November.

I would plan to finish before 31 October and confirm the current guidance with the app owner. The classic CRM card migration guide explains the source conflict, replacement testing and view migration. This retirement concerns the legacy technology, not every record card.

Decide whether the work is worth maintaining

Compare the repeated lookup or missed step with the effort of building and maintaining the card. Check whether users act on the information and whether a simpler record layout solves the problem.

The custom app cards page describes the development scope and platform conditions. Questions about a particular record interface? You're welcome to compare notes.