Custom Objects

This guide documents all custom objects in the Suger Salesforce App. These objects store marketplace data synced from AWS, Azure, GCP, and Snowflake marketplaces.

How to Read the Field Tables

Every field table below carries a Populated From column: the source value Suger writes into that Salesforce field, and any conversion applied on the way.

Which Partners Populate Which Objects

The Referral object splits its fields by prefix — AWS_, AZURE_, GCP_, PRM_ — and only the prefix block matching the referral’s partner is populated. A referral from AWS leaves every AZURE_, GCP_ and PRM_ field empty, and vice versa. The unprefixed Common Fields populate for every partner.

Referral_Bulk_Share_Job, Suger_Organization, View, and Referral_Lookup_Filter are written by the app itself rather than by the marketplace sync, so their tables carry no Populated From column.

Object Categories

Object Relationship Overview

The Suger data model centers around marketplace transactions across multiple cloud platforms:

Core Marketplace Objects

Buyer__c

Represents cloud marketplace customers/buyers who purchase products through AWS, Azure, GCP, or Snowflake marketplaces.

Product__c

Represents products listed across cloud marketplaces. Products are the foundation for creating offers.

Offer__c

Represents marketplace offers (private offers, CPPO, etc.) with approval workflows and expiration tracking.

Entitlement__c

Represents customer entitlements in cloud marketplaces after offer acceptance. Tracks active subscriptions and usage.

EntitlementTerm__c

Tracks specific terms, commitments, and credits for entitlements over their lifecycle.

RevenueRecord__c

Tracks financial transactions and commission tracking for cloud marketplace deals.

OfferDimension__c

Represents metering dimensions on an Offer (the priced units that the offer charges for). Each Offer can have multiple dimensions; this table makes them queryable as first-class records.

OfferPaymentInstallment__c

Represents the payment-schedule installments on an Offer (the planned payments a private offer charges for). Each Offer can have multiple installments; this table makes them queryable as first-class records. Populated by the Suger → Salesforce backfill.

Opportunity_Offer__c

Junction object linking a Salesforce Opportunity to a Suger Offer. Allows a single opportunity to be associated with multiple offers (and vice-versa) when the “Enable Offer Set In Opportunity Level” setting is on.

Co-Sell Objects

Referral__c

Represents partner referrals with extensive platform-specific fields for AWS, Azure, GCP, and Suger PRM co-sell programs.

How many fields a referral actually fills. One referral belongs to exactly one partner, so it only ever populates the Common Fields plus its own prefix block:

Every other prefix block stays empty. The counts exclude fields marked not populated by sync in the tables below.

Source Records by Partner

Each partner’s fields come from a different upstream record. Knowing which one you have tells you which fields can be populated at all.

The 5 Azure fields that come from Microsoft’s copy, not yours:

AZURE_MS_ReferralStatus__c, AZURE_MS_ReferralSubStatus__c, AZURE_Microsoft_Contact_Name__c, AZURE_Microsoft_Contact_Email__c, AZURE_AssistanceRequestCode__c

Microsoft’s copy exists only once Microsoft has engaged with the referral. Until then these five stay empty while your copy’s 28 fields are already populated — an empty AZURE_MS_ReferralStatus__c means “Microsoft has not engaged yet”, not “the sync failed”. AZURE_AssistanceRequestCode__c is the exception that still gets a value without Microsoft’s copy: it defaults to No help required.

GCP sub-objects that arrive late. These GCP_ fields stay empty until Google approves the opportunity, and are not a sync problem:

Common Fields

AWS Fields

Which source record fills them: Engagement Invitation vs ACE Opportunity

An AWS referral is written from one of two AWS records, never both at once, and which one you have depends on where the deal sits in its lifecycle. Both write to the same Suger__Referral__c row.

So a pending invitation gives you 19 fields and nothing else. Everything else stays empty until you accept.

The complete Engagement Invitation field set

These are every field a pending or rejected invitation can fill. Paths are relative to the ACE EngagementInvitation.

AWS_InvitationMessage__c is on both packaged Referral page layouts (Referral Layout and Referral Layout V2), so the sender’s covering note is visible without customizing a layout first. It is a Long Text Area holding up to 32,768 characters, so the whole message is kept rather than truncated.

Of those 19, 12 are re-written from the ACE Opportunity once you accept (from a different path — for example AWS_CustomerCompanyName__c moves from Payload.Customer.CompanyName to Customer.Account.CompanyName). The 5 marked invitation-only have no counterpart on the Opportunity, so they keep their invitation values permanently and are how you tell, after the fact, that a referral arrived as an invitation.

The topical tables below cover the ACE Opportunity field set. Where a field can also come from an invitation, its Populated From cell shows both, as Customer.Account.CompanyName · invitation: Payload.Customer.CompanyName.

Account & Contact Information:

Opportunity & Deal Information:

Location Information:

Classification & Programs:

Marketing & Activities:

Dates & Status:

Additional Information:

Azure Fields

Customer Information:

Location Information:

Referral Status & Type:

Deal & Solution Information:

Microsoft Contact & Metadata:

GCP Fields

Basic Information:

Customer Information:

Contact & Location:

Deal Information:

Dates & Status:

Products & Services:

Classifications & Attributes:

Extensions & Rebates:

Win/Loss Information:

Additional Fields:

PRM (Suger Co-Sell) Fields

Populated for co-sell referrals shared through Suger PRM — partner-to-partner (org-to-org) co-sells. Only the minimal important deal information is synced; commission / revenue-share terms are intentionally not exposed.

Contact__c

Stores partner contacts (e.g., AWS PDM, Azure PM, GCP PSO) associated with referrals and accounts. Used in co-sell flows to identify the partner-side person managing a deal.

Lead__c

Represents AWS lead invitations and the leads they convert into. Written only for the AWS partner — Azure and GCP have no equivalent lead object. Salesforce shows the object as Lead (Suger) / Leads (Suger), keeping it distinct from the standard Salesforce Lead object.

To work these records in the app rather than report on them, see Work AWS Co-Sell Leads — the Leads V2 (Suger) tab reads live from Suger, so it can differ from the backfilled fields below between sync runs.

Referral_Bulk_Share_Job__c

Tracks the status of bulk referral share jobs (e.g., sharing many referrals to a cloud partner in one operation). Used by the admin UI to monitor progress and surface failures.

Funding Objects

Funding__c

Tracks funding programs and cash/credit requests from cloud marketplace partners.

FundingCashClaim__c

Tracks individual cash claims against funding requests.

Configuration Objects

These objects store app-wide configuration that affects how the Suger Salesforce App behaves. They are typically managed by administrators, not end users.

Suger_Organization__c

Stores the connection between the Suger Salesforce App and the Suger backend (API credentials, OAuth client info, organization-level feature toggles).

View__c

Stores user-saved list view configurations (column choices, filters, sort order) for Suger object pages in the Console. Allows admins to create reusable, shareable views.

Custom Metadata Types

Referral_Lookup_Filter__mdt

Configurable lookup filters for the Referral object. Allows admins to define filter criteria for Opportunity and Account lookups on referral records.

How to Configure

1. Click the Gear Icon (⚙️) > Setup.

2. In the Quick Find box, type Custom Metadata Types.

3. Locate the row labeled Referral Lookup Filter (Namespace Prefix: SUGER) and click Manage Records.

4. Click New to create a new filter rule.

5. Fill in the fields and click Save.

Filter Condition Syntax

The Filter_Condition__c field accepts SOQL-like filter expressions with these features:

Supported Operators:

Logical Operators:

• AND - Both conditions must be true
• OR - Either condition must be true
• () - Parentheses for grouping (supports nesting)

Value Types:

Dynamic Field References:

Reference values from the Referral record using {ObjectName__c.FieldName__c} syntax:

Name = {Referral__c.AWS_CustomerCompanyName__c}
Suger__Hyperscaler__c = {Referral__c.Partner__c}

Relationship fields are also supported:

Account.Name = {Referral__c.Account__r.Name}

Example Filter Conditions

Filter Opportunities by Stage:

StageName NOT IN ('Closed Lost', 'Closed Won')

Filter by Amount and Type:

Amount > 10000 AND Type IN ('New Business', 'Expansion')

Complex Filter with Dynamic References:

Type IN ('1P', 'Standard') AND StageName NOT IN ('Closed Lost', 'Closed Won') AND Suger__CosellShared__c = false AND (Suger__Hyperscaler__c = {Referral__c.Partner__c} OR Suger__Hyperscaler__c = '' OR Suger__Hyperscaler__c = null)

Searching by an Additional Field

By default, the record picker in the referral Link Opportunity / Link Account dialogs matches your search text against the record Name only. To also search by another field — for example an opportunity number like OPP-002370084 — set Search Field (Search_Field__c) to that field’s API name:

With this record active, typing either an opportunity name or an opportunity number in the picker finds the record, and the configured field is shown next to each suggestion.