Page Components

Suger ships a set of Lightning components you can drop onto record, app, and home pages with the Lightning App Builder — no code required. They surface Suger’s co-sell and marketplace functionality directly inside your Salesforce record pages.

These are separate from Quick Actions (the action buttons in the highlights panel) — the components below are full panels and cards you place in the body of a page.

Overview

There are two kinds of things you can add to a Salesforce record page, and they appear in different places:

You can add one or both. Most teams add both — the widget for visibility and the buttons for quick access. This page covers the page components; see Quick Actions for the buttons.

Prerequisites

• The Suger App must be installed and connected to Salesforce. See the Salesforce integration setup guide.
• Your team must have Suger permission sets assigned. See Permission Sets. Permission sets control which components and buttons each person actually sees — adding a component to the page without assigning permission sets means those users will see nothing.
• You need Salesforce Administrator access to edit page layouts and record pages.

How to add a component

1. Open the record (or app/home) page you want to edit and choose Setup (⚙️) → Edit Page to open the Lightning App Builder.
2. In the Components list on the left, scroll to the Custom (managed) section and find the Suger component by name (e.g. Suger Opportunity Quick Panel).
3. Drag it onto the page where you want it to appear.
4. Save, then Activate the page (as org default, or by app/profile, as needed).

Opportunity components

These surface Suger on the Opportunity record page — the main workspace for a sales rep.

Associated Contacts on an opportunity

The Associated Contacts section of the Opportunity Quick Panel is scoped to the clouds this opportunity was actually shared with: once the opportunity carries at least one cloud referral, the section shows partner contacts for those clouds only, instead of every cloud your org has integrated.

Two deliberate exceptions keep the scope from hiding contacts you are entitled to:

• No visible cloud referral, no filter. If the opportunity has no cloud referrals — a PRM-only deal, for example — or the referral list could not be read, the scope is treated as unknown and every cloud is shown.
• A cloud you cannot read stays in scope. Not seeing a cloud’s referrals is not evidence there are none, so a cloud whose referrals your permission set hides is never filtered out. A user with a single-cloud read grant therefore always sees the section unfiltered.

Suger Account Insights

Suger Account Insights is the one component that works on both Account and Opportunity pages, and it renders differently on each. On an Opportunity page it is a compact insight line; on an Account page it is a full widget covering the customer’s marketplace activity, co-sell referrals, funding requests, and the partner contacts who cover them.

On both Account and Opportunity pages

The component opens with an engagement-score line for the customer, drawn from the cloud partner’s own view of the account (AWS, Azure, or GCP).

On Account pages only

Below the score, an Account page adds a tab switcher. Marketplace is always there; the rest appear when your org has the feature configured and the user has access to it:

Finding an offer. Once there is at least one active offer, a search box appears above the list. It filters the offers already loaded in the widget by offer name, offer ID, buyer account ID, or product name — it does not re-query the server, so results come back as you type.

List vs. Board. A List / Board toggle switches between the row view and the card view. List is the default wherever the component has at least 600px of width — it fits far more offers on screen and lines their status and acceptance up in comparable columns — and your last choice is remembered, so a user who switched to Board lands back on Board. The toggle is a property of the whole widget, so flipping it changes both Active Offers and Active Entitlements at once. Below 600px there is no room for the list’s seven columns, so the toggle is hidden and Board is used regardless of the stored preference.

Rows carry the identifiers you need to reconcile a record against the marketplace:

Offer rows also carry the offer’s external ID, product name, create and expire dates, and — once accepted — the acceptance date. Entitlement rows carry the external ID, product name, status, type, and start and end dates. Identifier values can be copied straight from the row.

The buyer block is named for the cloud. An offer card lists the accounts the offer was made out to under a heading that uses each cloud’s own word for them: Buyer account / Buyer accounts for AWS, Billing account / Billing accounts for GCP, Buyer ID / Buyer IDs for Azure.

Each buyer row carries its own status badge, derived from the entitlement behind it rather than from the offer:

The card’s own status badge additionally shows Partially accepted when some buyer accounts on a multi-buyer offer have accepted and the rest are still pending. Hovering a card status explains it in plain language.

What the count counts. M is the number of accounts the offer was made out to — not the number of agreements that exist. On AWS a targeted account can distribute grants to other accounts that the offer never named; each of those produces its own agreement. Those agreements appear in Active Entitlements, but they are deliberately not counted as acceptances of the offer, because the accounts holding them were never targeted by it. This is why an offer can read 1 of 1 accepted while the AWS console shows several active agreements for the same customer.

A multi-buyer offer also carries an acceptance count beside its status, written as N of M — for example 1 of 2. When entitlements could not all be read, the count reads at least N of M, because the true number can only be higher than the rows Suger could see. On an offer set the same shape counts member offers rather than buyers: 1 of 2 accepted means one of the two offers in the set is fully accepted.

Acceptance Date on an offer. An offer made out to more than one buyer shows a dash (—) here rather than a date, and the tooltip points you to the entitlements below. This is deliberate: each buyer accepts separately, so there is no single date that belongs to the offer — the per-buyer rows carry each real one. An offer with a single buyer shows that buyer’s acceptance date as normal. A dash also appears when no acceptance date was recorded on the offer at all; the two cases have different tooltips.

End Date on an entitlement. An agreement with no scheduled end reads No end date. That is a statement about the contract, not a gap in Suger’s data — an entitlement whose end date has not been synced shows no End Date row at all.

Actions on an offer card. Two buttons sit at the bottom of the card while the offer still needs someone to accept it:

Both actions — and the whole action row — disappear once every targeted buyer has accepted: the acceptance link is spent at that point, and offering it would invite a seller to chase a customer who has already signed.

GCP universal PAYG discount. When a GCP offer was priced with one discount across all usage rather than per-dimension rates, the card shows a banner above the buyer block reading the discount — for example 20% off all usage — captioned Universal PAYG discount.

Object detail cards

Read-only detail views of a Suger record, shown on that object’s record page. They already ship on Suger’s packaged record pages; add them here only if you’re building a custom page for one of these objects.

To add one, follow the same steps as adding a widget — open the object’s record page in the Lightning App Builder, find the card in the Custom components section, and drag it onto the canvas.

Suger Entitlement Detail Card

Amendment banner. When the offer currently linked to an entitlement is a replacement (amendment) offer, an info banner sits above the field grid reading:

This entitlement originated from an amendment. It is now storing the information for offer {offer name}.

Suger relinks the entitlement onto the accepted replacement offer, so the banner is there to explain why the entitlement’s offer details are no longer the ones the buyer originally accepted.

Linking an opportunity to a public-offer entitlement. Entitlements that came from a public offer — a DEFAULT or FREE_TRIAL listing offer — can be linked to a Salesforce Opportunity from this card. A public offer is buyer-agnostic and can never carry a link to one specific opportunity, so the link is stored on the individual entitlement rather than on the shared offer. For private-offer entitlements the link continues to live on the offer, which then propagates it to every entitlement under that offer.

Troubleshooting

Frequently asked questions

Do I need to add the widget and the quick action buttons, or just one? You can add either or both — they serve different purposes. The widget shows a full view of offers and referrals linked to the record. The quick action buttons give reps a shortcut to create something new without scrolling to the widget first. Most teams use both.

Can I add the Suger widget to Account or Contact pages too? The opportunity-specific panels (like Suger Opportunity Quick Panel) are locked to the Opportunity object and won’t appear on other page types. The Suger Account Insights component is available on both Account and Opportunity pages — and the Account page gets the fuller version: not just the engagement score, but the Marketplace / Co-Sell / Funding / Contacts switcher, showing only the tabs your org has configured and the user has access to. See Suger Account Insights. There is no Suger component for the Contact object.

I added Suger Account Insights to my Account page, but a tab is missing. Each optional tab has its own requirement. Co-Sell and Contacts both need a co-sell integration plus read access to at least one of AWS, Azure, or GCP — Co-Sell specifically needs referral read, so marketplace-only access is not enough. Funding needs funding read or write access. In a marketplace-only org there is nothing to switch to, so the tab switcher is dropped entirely and the Marketplace content renders on its own. If the Contacts tab is there but Associated Contacts is empty, check that the Account record has a Website — Suger matches partner contacts by the account’s company domain. See Suger Account Insights.

Can different teams see different widgets on the same opportunity page? Yes — you can activate different page layouts by app or profile in the Lightning App Builder. For example, your marketplace team can have a page showing the offers widget, while your co-sell team sees the referrals widget.

When would I need to add an object detail card manually? Only when you’re building a custom record page for a Suger object like Offer or Referral. If you’re using Suger’s default packaged record pages, the detail cards are already included and don’t need to be added manually.

Related

• Quick Actions — the Suger action buttons (Co-Sell, Create Offer, etc.) for the highlights panel.
• Permission Sets — control which users see Suger tabs, components, and actions.