# Page Components Fours 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 Fours' co-sell and marketplace functionality directly inside your Salesforce record pages. These are separate from [Quick Actions](/salesforce-app/salesforce-app-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: | What | Where it appears | What it does | | ---- | ---------------- | ------------ | | **Page components** (widgets and cards) | The body of the record page, below the highlights panel | Show Fours offers, referrals, entitlements, and insights linked to the record, and let users act from there | | **[Quick Actions](/salesforce-app/salesforce-app-quick-actions/)** (action buttons) | The highlights panel at the very top of the record page | One-click buttons like _New Offer via Suger_ and _Co-Sell via Suger_ that open a focused flow immediately | 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](/salesforce-app/salesforce-app-quick-actions/) for the buttons. ### Prerequisites - The Fours App must be installed and connected to Salesforce. See the [Salesforce integration setup guide](/integrations/salesforce/). - Your team must have Fours permission sets assigned. See [Permission Sets](/salesforce-app/salesforce-app-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 Fours 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). :::note Each component only appears in the App Builder on the page types it supports, and some are **locked to specific objects** (noted below) — they won't show up when you're editing another object's page. ::: :::tip **Don't forget to click Activate.** Saving the page in the Lightning App Builder does not publish it to users — you must also activate it. You can activate as **Org Default** for everyone, or by app or profile for more control. ::: --- ## Opportunity components These surface Fours on the **Opportunity** record page — the main workspace for a sales rep. | Component | What it does | | --------- | ------------ | | **Suger Opportunity Quick Panel** | The primary, all-in-one Fours widget — surfaces co-sell **and** marketplace together in a single panel. The Marketplace tab lists the opportunity's offers and entitlements; the Co-Sell tab also carries a **Leads** section for the opportunity's Account, where you can [enrich that Account into an AWS lead](/salesforce-app/salesforce-app-leads/#enrich-an-account-into-an-aws-lead). Use this when you want one component that does everything. | | **Suger Cosell Actions Quick Panel** | The co-sell **actions** — share the opportunity as a referral with AWS, Azure, or GCP and run co-sell operations. _(Locked to Opportunity.)_ | | **Suger Cosell Referrals Quick Panel** | The co-sell **list** — the referrals created from or linked to this opportunity. _(Locked to Opportunity.)_ | | **Suger Marketplace Actions Quick Panel** | The marketplace **actions** — create private offers and related operations. _(Locked to Opportunity.)_ | | **Suger Marketplace Offers Quick Panel** | The marketplace **list** — the offers linked to this opportunity. _(Locked to Opportunity.)_ | | **Suger Cosell Leads Quick Panel** | The [AWS co-sell leads](/salesforce-app/salesforce-app-leads/) attached to this opportunity. _(Locked to Opportunity.)_ | | **Suger Account Insights** | The customer's full picture — a **Suger Predicted Engagement Score** line on both page types, plus a **Marketplace / Co-Sell / Funding / Contacts** widget when placed on an Account page. _(Available on Account and Opportunity pages — see [Suger Account Insights](#suger-account-insights) below.)_ | :::tip The Quick Panels come as an **Actions + List** pair for each area (Co-Sell and Marketplace), so you can place them independently — for example, the actions panel near the top of the page and the list further down. Prefer the **Suger Opportunity Quick Panel** if you'd rather have a single combined widget instead. ::: ### 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: Fours' 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](/cosell/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: | Tab | What it shows | When it appears | | --- | ------------- | --------------- | | **Marketplace** | **Active Offers** — the account's live offers — followed by **Active Entitlements**, the contracts currently running for this account. | Always. | | **Co-Sell** | **Referrals** across the account's opportunities, plus any linked to the account directly. Read-only — referrals are created from the Opportunity page, which carries the context they need. Below them, **Leads** — the account's AWS co-sell leads, with **Create & enrich** / **Re-enrich** to [send the account to AWS for lead enrichment](/salesforce-app/salesforce-app-leads/#enrich-an-account-into-an-aws-lead). | Co-sell is configured for your org and the user can read referrals for at least one cloud. The **Leads** section itself needs AWS referral read. | | **Funding** | **Funding Requests** — AWS funding reached two ways: linked to one of the account's opportunities, or found through the account's AWS co-sell referrals. Funding attaches to an AWS co-sell opportunity, never to the account itself, so a referral linked straight to the account still surfaces its funding even with no Salesforce opportunity involved. Read-only. | The user has funding read or write access. | | **Contacts** | **Buyer Contacts** — the account's own people, taken from its offers (see [Buyer Contacts](#buyer-contacts) below). When co-sell is configured for your org, also **Associated Contacts** — the partner contacts linked to this account. | The user can read AWS, Azure, or GCP referrals **or offers**. Co-sell is not required. | :::note The Funding tab scans a recent page of referrals rather than every one, so on an account with a lot of co-sell history the list can be partial. When that limit is reached the tab says so above the rows. ::: Each of these tabs that has rows carries its own **List / Board** toggle and its own **search box**, and remembers its List/Board choice independently — see **List vs. Board** below. **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 — together with the search box — appears on **each tab that has rows** (Marketplace, Co-Sell, Funding, and Contacts), and **each tab keeps its own List / Board choice**: switching Marketplace to Board leaves Co-Sell on List until you switch it too. 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: | Row field | Appears on | What it is | | --------- | ---------- | ---------- | | **Partner ID** | Offers and entitlements | The seller marketplace integration account that owns the offer or entitlement — for AWS, the 12-digit seller AWS account ID. | | **Billing account** | Offers and entitlements | The buyer's account on the cloud side. Named the same way on every marketplace — see below. | | **Contract Term** | Offers | The term the offer runs for, normalized from however that cloud states it. | | **Reseller ID** | Offers, CPPO only | The reseller on a channel deal — shown only when the offer is a [reseller authorization / CPPO](/salesforce-app/salesforce-app-cppo/), inbound or outbound. | 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: | Badge | What it means | | ----- | ------------- | | **Accepted** | The buyer accepted; an agreement exists (also shown while the agreement is scheduled to start). | | **Pending acceptance** | The buyer has produced no entitlement yet. | | **Suspended** | The agreement is suspended. | | **Cancellation pending** | Cancellation has been requested and is not yet complete. | | **Cancelled** | The agreement was cancelled. | | **Replaced**, **Renewed**, **Superseded** | The marketplace cancelled the agreement because a newer one took over. The three are kept distinct because a renewal is not a replacement. | | **Acceptance unknown** | Fours could not read all of this customer's entitlements, so a buyer who has accepted may still read as unknown. This is now rare: it means the Fours API could not be reached, a buyer lookup failed, or the account holds more entitlements than Fours will page through in one load. A large account on its own no longer causes it. Refresh the page; if it persists, contact Fours support. | 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 Fours 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 Fours' 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 Fours 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 Fours 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: | Action | What it does | | ------ | ------------ | | **Send reminder to contacts** | Opens the reminder prompt, which lists the offer's notification contacts — plus **Suggestions** from the account when contact routing is on — and mails a reminder to the people you tick. If you hold the **Modify Offer Contacts** custom permission or write access to that cloud's offers, **Add contact** inside the prompt attaches another person first — offered whether the list is empty or already populated. | | **Copy private offer URL** | Copies the buyer-facing acceptance link. Shown only once the marketplace has returned a URL. | 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. **Who the reminder goes to.** The prompt lists the offer's own notification contacts, already ticked. When contact routing is on (see [Buyer Contacts](#buyer-contacts)) and the offer's product carries a product line, a **Suggestions** list follows: people on this account filed under that product line who are not on the offer yet, each with a product-line badge, unticked. Tick a suggestion and Fours adds that person to the offer's notification contacts before sending, so a reminder can reach routed contacts even when the offer has none of its own. The button counts the emails it is about to send — **Send 1 reminder**, **Send 3 reminders** — and stays disabled until someone is ticked. When the offer has no contacts and nobody is suggested, the prompt goes straight to **Add contact** if you are allowed to add one. ```d2 direction: right own: "Offer's notification contacts\n(ticked)" suggested: "Suggestions: account people\nunder the offer's product line\n(unticked)" pick: "You tick who\nshould be reminded" attach: "Ticked suggestions are\nadded to the offer" send: "Reminder emailed to\neveryone ticked" own -> pick suggested -> pick pick -> attach -> send ``` **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. ```d2 direction: right offers: "People named on\nthis account's offers" domain: "People at the Account's domain\nfiled under one of its\nproduct lines\n(contact routing on only)" filter: "Keep the Account's\nown email domain" routing: "Contact routing on?" { shape: diamond } rows: "One row per product line\nyour products carry,\nplus Unassigned" flat: "One ungrouped list" offers -> filter domain -> filter filter -> routing routing -> rows: "yes" routing -> flat: "no" ``` How the list is organized depends on **Contact routing**, a switch under **Product Tagging** in the private offer settings of the Fours Console: | Contact routing | What the panel shows | | --------------- | -------------------- | | **On** | One row for **every product line your org's products carry**, in alphabetical order, each with a count — including lines nobody on this account is filed under yet, so there is always a row to file the account's first contact under. Expand a row to see its people. People with no product line are grouped under **Unassigned**. | | **Off** | The account's people as one ungrouped list. | The rows come from your products, not from this account's offers, so an account with no Fours offers still shows every line. The domain filter still applies to the people inside each row: a row whose people are all at other domains stays on the panel, empty. A search box (*Search contacts (name, email, tag)*) filters the list as you type — it also matches a product line's own name, so you can reach an empty line by typing it — 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. It is disabled, with the tooltip *Set this account's website to enable*, until the Account has a **Website** — filing someone needs a domain to show them against. 1. Click **Add contact** on the row. 2. Pick the person in the contact picker — a Salesforce contact or user, an existing Fours contact, or a new one. The picker opens on **Create Suger Contact**, for someone new. 3. Fours 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 *This panel lists the people on this account's offers, and those at its email domain. Add them to one of its 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](/salesforce-app/salesforce-app-custom-permissions/). If a load, add, or remove fails, the message ends *if it keeps failing, contact Suger*. The panel shows a spinner until the account's offers have loaded, then *No contacts on this account yet* only when there is nobody to list **and** no product-line row to show — with contact routing on and tagged products, the rows are always there. :::note **The tab switcher only renders on an Account page.** On an **Opportunity** page there is no switcher at all — just the Suger Predicted Engagement Score line. The switcher is also dropped when Marketplace is the only tab you qualify for. With nothing to switch to, the Marketplace content simply renders on its own rather than behind a one-button switcher. Inside the Contacts tab, **Associated Contacts** appears when your org has co-sell configured, and it needs the Account to have a **Website** — Fours matches partner contacts to an account by its company domain. An account with an empty Website field has nothing to match on, so the tab shows **"No associated contacts to display"**, noting that the account has no Website set. Fill in the Website and reload the page. **Buyer Contacts** works without a Website: it then lists everyone the account's offers name. ::: --- ## Object detail cards Read-only **detail views** of a Fours record, shown on that object's record page. They already ship on Fours' 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. | Component | Record page | | --------- | ----------- | | **Suger Buyer Detail Card** | Buyer | | **Suger Entitlement Detail Card** | Entitlement | | **Suger Offer Detail Card** | Offer | | **Suger Product Detail Card** | Product | | **Suger Referral Detail Card** | Referral | ### 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}*. Fours 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 | Issue | Possible cause | Resolution | | ----- | -------------- | ---------- | | Fours component is not visible in the **Components** panel | The Fours package isn't installed, or the page type doesn't support the component | Confirm the Fours App is installed. Fours components only appear on supported page types — opportunity-specific components won't show when editing Account or Contact pages. | | Component is on the page but shows a **"Feature Disabled"** message | The feature has been disabled in Fours App Settings | In the Suger app in Salesforce, go to **Settings → Tabs Control** and turn off the toggle for the relevant feature. | | Buttons appear on the page but users can't see them | The user doesn't have the correct Fours permission set assigned | In **Setup → Permission Sets**, assign the appropriate [Fours permission set](/salesforce-app/salesforce-app-permission-sets/). | | Page changes aren't showing for users after saving | The page was saved but not activated | Return to the Lightning App Builder and click **Activate**. | --- ## 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](/salesforce-app/salesforce-app-quick-actions/) give reps a shortcut to create something new without scrolling to the widget first. Most teams use both. **Can I add the Fours 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](#suger-account-insights). There is no Fours 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** — Fours matches partner contacts by the account's company domain. See [Suger Account Insights](#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 Fours object like Offer or Referral. If you're using Fours' default packaged record pages, the detail cards are already included and don't need to be added manually. --- ## Related - [Quick Actions](/salesforce-app/salesforce-app-quick-actions/) — the Fours action buttons (Co-Sell, Create Offer, etc.) for the highlights panel. - [Permission Sets](/salesforce-app/salesforce-app-permission-sets/) — control which users see Fours tabs, components, and actions.