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 a Suger Predicted Engagement Score line for the customer: Suger’s own prediction of how likely this customer is to buy through AWS, Azure, or GCP, from marketplace activity and third-party signals. It is not the score a cloud partner gives an opportunity — that one appears on the referral as Engagement Score — and it is not stored on the Referral record, so it does not appear in reports built on that object. The heading’s tooltip says the same.

The same line also heads the Suger Opportunity Quick Panel and the Suger Cosell Actions Quick Panel. See Co-sell Insights for how the two scores differ.

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, billing 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.

Sorting the list. In List view the Created and Expires column headers are buttons. The list opens sorted by Created, newest first; clicking a header sorts by it, and clicking the same header again reverses the direction. The header shows which is active — ⇅ while idle, an up or down arrow once it is the sort column. Sorting is a property of the List view only: Board groups cards by status and is not sorted.

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 has one name on every cloud. An offer card lists the accounts the offer was made out to under Billing account / Billing accounts — on AWS, on GCP, on Azure, and on any marketplace not named there (Snowflake, Oracle, Alibaba Cloud) as well.

The widget used to mirror each cloud’s own word for it — “buyer account” on AWS, “billing account” on GCP, “buyer ID” on Azure — which taught sellers three names for one column. A cross-cloud widget uses the cross-cloud name. That name is now used in four places at once: the Board view’s card block, the List view’s column header on both Active Offers and Active Entitlements, the offer search box, and the expanded entitlement card.

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.

A marketplace signals “no scheduled end” with a far-future date rather than an empty one, so a subscription agreement carries an end date in the year 9999. Every Suger surface resolves that to No end date instead of printing it: the account widget, the offer page, the entitlement detail page, and the entitlement list. If you ever see a date in 9999 on a Salesforce record, it came from a field Suger did not render — a formula or report built directly on the raw value — not from the app.

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.

Buyer Contacts

The Contacts tab opens with Buyer Contacts: the account’s own people, taken from the offers on this account. When the Account has a Website, only addresses at that domain or one of its subdomains are listed, so your own reps and anyone else named on an offer are left out. With no Website, everyone the offers name is listed. Partner and seller reps are never included.

How the list is organized depends on Contact routing, a switch under Product Tagging in the private offer settings of the Suger Console:

A search box (Search contacts (name, email, tag)) filters the list as you type, and Expand all / Collapse all opens or closes every row at once.

File a contact under a product line. With contact routing on, each product-line row has an Add contact button:

1. Click Add contact on the row.
2. Pick the person in the contact picker — a Salesforce contact or user, an existing Suger contact, or a new one.
3. Suger files them under that product line and reloads the panel. The confirmation tells you where they landed:
   • Contact added to {product line}. — they now appear in that row.
   • Filed under {product line}, but not shown here. — the filing worked, but the panel lists only people at this account’s email domain. Put them on one of this account’s offers to see them here.

A trash icon (Remove from this product line) appears only on people filed by hand. Removing one confirms with Contact removed from {product line}. People placed by contact routing follow their offer’s product, so they have no trash icon.

Adding and removing need the Modify Offer Contacts custom permission — Create Offer does not grant it here. See Custom Permissions. An account with nobody to list shows No contacts on this account yet.

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.

Organization. GCP private offers name a customer organization, so entitlements and offers that came from one carry an extra Organization tile at the top of the card. No other marketplace puts a customer organization on its offer, so the tile is not shown for them at all — it is omitted rather than rendered “N/A”, which is also how the sub-status tile behaves. An empty header tile reads as missing data; an absent one reads as “this cloud has no such field,” which is the true statement.

GCP dates in Pacific time. A GCP entitlement’s Start Date and End Date show as a Pacific date and time with the PST or PDT label, matching GCP’s Producer Portal. The Suger Entitlement page shows them the same way. Entitlements on other marketplaces keep showing the date alone.

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 Suger Predicted 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 needs a co-sell integration plus referral read access, so marketplace-only access is not enough. Contacts needs read access to AWS, Azure, or GCP referrals or offers, and does not need co-sell. Funding needs funding read or write access. When Marketplace is the only tab you qualify for, the tab switcher is dropped entirely and the Marketplace content renders on its own. If the Contacts tab is there but Associated Contacts is missing or empty, check that your org has co-sell configured and 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.