Salesforce terms starting with G

Generate Orders is the action in Salesforce CPQ and Salesforce Order Management that turns a closed quote or contract into one or more Order records, with their associated Order Products (line items) and, optionally, Order Schedules. It is the bridge between the selling motion (Opportunity, Quote, Contract) and the fulfillment motion (Order, Asset, Subscription, Invoice). Without an Order, downstream revenue recognition, billing, fulfillment, and asset tracking have no source record to operate on. Salesforce ships order generation in two distinct products. Salesforce CPQ generates orders from a contracted quote, splitting lines into multiple orders by date, location, or product family if needed. Salesforce Order Management (a Service Cloud add-on aimed at B2C and B2B retail) generates orders from external commerce systems and from the Order REST API. The term Generate Orders specifically references the CPQ-side action triggered by a button or a flow; Order Management refers to the same operation as Order Creation. Both write to the standard Order and OrderItem objects.

A GET Request in the Salesforce context is an HTTP request using the GET method, typically used to read data from a REST API. The Salesforce platform consumes and produces GET requests across several integration surfaces: Apex HTTP callouts use HttpRequest.setMethod('GET') to read from external APIs; the Salesforce REST API exposes endpoints like /services/data/v60.0/sobjects/Account that respond to GET with sObject data; External Services and Named Credentials wrap GET callouts as declarative actions in flows; and Visualforce remoting historically used GET for read-only Apex method calls. GET is the default and safest HTTP verb in any integration because it carries no payload, can be cached by intermediaries, and is idempotent (calling it twice produces the same result as calling it once). Salesforce enforces a 6-MB synchronous response size limit, a 120-second timeout, and the standard per-org callout limits regardless of whether the call is GET or another verb. Authentication, headers, and query-string parameters travel with the GET; the response body carries the payload.

Getter Methods in Apex are the public accessors that expose the value of a class property to outside callers. The pattern follows standard object-oriented practice: a private instance variable holds the data, and a public method (or property accessor) returns it. Apex supports the explicit Java-style getX() naming convention and the more concise C#-style property syntax with implicit get and set blocks, both compiling to the same underlying method. Getter methods appear most often in Visualforce controllers, where every public property on the controller class is exposed to the page via {!propertyName}, and in Lightning Web Component @AuraEnabled methods, where they let JavaScript read computed values from Apex. Getters can hold computation, lazy loading, caching, or pure field returns. The trade-off is the same as in any platform: pure getters are predictable; computational getters can be slow when called inside loops or rendered many times per page request.

A Global Action is a Salesforce Quick Action that lives outside any specific object and can be invoked from anywhere in the platform: the App Launcher header (plus icon), the Lightning utility bar, the mobile app, or programmatically through a Flow. Global Actions let users create records, log calls, send emails, or run a Flow without first navigating to a specific record. The classic use case is the New Task or New Event entry point in the Lightning header: it sits above every page and creates a Task without requiring a related record context. Global Actions differ from Object-Specific Actions in two ways. They are not tied to a specific sObject, so they appear in the header and mobile launchpad regardless of which record the user is on. They also do not auto-link the new record to the current page; an Object-Specific Quick Action on Account creates a Task already linked to the Account, while a Global Action creates a free-standing Task. Global Actions are the lighter-weight pattern for "start something new" workflows that are not contextually tied to an existing record.

Global Search is the Salesforce search bar at the top of every Lightning Experience page that queries across multiple objects and surfaces matching records, files, and Knowledge articles in one ranked result list. The search uses the same Apache Lucene-based engine that powers Knowledge search and the App Launcher search. Typing a query like "Acme" returns Accounts named Acme, Contacts at Acme, Cases referencing Acme, and any other indexed object that matches. The results respect sharing: users only see records they have permission to view. Global Search is the primary navigation pattern for users who know what they want but not where it lives. The search index covers all standard objects, custom objects with searchable fields, Files (Content Documents), and Knowledge Articles by default. Search behavior is governed by Search Layouts (which fields appear in the result snippet), Synonym Groups (admin-defined word equivalents), and Promoted Search Terms (admin-pinned results for specific queries). Together these tools shape how the search behaves for end users, with the index refreshed in near-real-time as records change.

A Global Variable in Salesforce is a system-provided value, prefixed with a dollar sign, that gives formulas, Visualforce pages, Lightning Web Components, Aura components, and other declarative tools access to contextual information about the current user, organization, environment, or platform metadata. Common examples include $User (current user fields like $User.Id, $User.Email, $User.ProfileId), $Profile (current user's profile fields), $Organization (org-level fields like $Organization.Id), $Setup (custom setting values), $Label (custom label values for translated text), $Action (URL or behavior for standard actions), and $Resource (static resource references). Global Variables are how declarative customizations access information that would otherwise require Apex or SOQL. A formula field can reference $User.ProfileId without writing any code; a Visualforce page can show $Organization.Name without binding to a controller property; a Lightning Web Component can read $Resource references to images without computing URLs. The result is significantly simpler customization for the common cases where the system context (who is the user, what is the org, what time is it) determines behavior. Mastering Global Variables is one of the steps that distinguishes a productive admin from one who hits the limits of declarative tools quickly.

Gmail is Google's webmail service, used by hundreds of millions of business users as their primary email client. In the Salesforce context, Gmail is the most common integration target for sales-team email workflows: logging emails to the right Salesforce record, syncing contacts and calendars between Gmail and Salesforce, and surfacing Salesforce context inside the Gmail UI itself. Salesforce ships a Gmail integration (formerly Salesforce for Gmail, now part of the Salesforce Inbox family) that runs as a Chrome extension and a Google Workspace Marketplace add-on. The integration handles four core jobs. It surfaces Salesforce records (Lead, Contact, Account, Opportunity) inside the Gmail sidebar so reps see deal context without leaving the inbox. It lets reps log an email or attach it to a Salesforce record with one click. Einstein Activity Capture optionally syncs every email automatically without manual logging. And the same Google Workspace add-on extends into Google Calendar, doing the same record-context work for meetings. Setup happens once in Salesforce, once in Google Workspace, and once per user via Chrome.

Gmail Integration and Sync is the Setup node in Salesforce that controls how the org connects to Google Workspace for sales email and calendar workflows. It bundles three settings: the Gmail Integration (the Chrome extension and Google Workspace add-on that surface Salesforce records inside Gmail), the email-and-event capture engine (Einstein Activity Capture in modern orgs, Lightning Sync in older ones), and the per-user enablement that lets each rep connect their Google account to Salesforce. The node is the single place where an admin turns on the org-wide capabilities, assigns users to the sync configuration, and configures which fields and behaviors flow between Gmail and Salesforce. It does not configure the Google Workspace side; that work happens in the Google admin console. Salesforce treats the integration as a one-way capability flag from Setup; the actual data flow runs over OAuth tokens and the per-user consents granted at install time.

Government Cloud is the Salesforce edition designed for United States federal government, state and local government, and defense contractor customers requiring compliance with FedRAMP, DoD IL2, DoD IL4, IRS 1075, ITAR, and similar government security standards. Government Cloud runs in dedicated infrastructure isolated from the commercial Salesforce environment, with personnel access restricted to United States persons, data residency in the continental United States, and additional contractual commitments around inspection and audit rights. The edition is provisioned and billed separately from commercial Salesforce, with customers entering a specific contracting vehicle (GSA Schedule, SEWP, customer-direct) appropriate to their procurement model. Government Cloud is functionally similar to Salesforce Enterprise Edition but with several capability differences driven by the compliance constraints. Some features available in commercial Salesforce are not yet available in Government Cloud because they have not completed the additional compliance review. Other features may be available at a lag, arriving in Government Cloud one or two releases after their commercial debut. Customers in regulated sectors plan their roadmap accordingly, treating the Government Cloud feature availability as a planning constraint.

Governor Limits are the per-transaction caps that Salesforce enforces on every Apex execution, every SOQL query, every DML statement, every callout, and every heap allocation. They exist because Salesforce is a multitenant platform: one organization''s code runs on the same hardware as every other organization''s code, and unrestricted resource use by one tenant would degrade performance for all the others. Governor Limits enforce a hard ceiling so no single transaction can take more than its share. Every Apex transaction is bounded by a set of synchronous and asynchronous caps. Common synchronous limits include 100 SOQL queries, 150 DML statements, 50,000 records returned by SOQL, 10,000 records modified by DML, 10 seconds of CPU time, 6 MB of heap, and 100 callouts. Asynchronous transactions (Queueable, Future, Batch) get higher caps on most of these. Hitting a limit throws an uncatchable Apex exception; the entire transaction rolls back. Defensive design (bulkification, async patterns, selective queries) is mandatory in any production Apex codebase.

Gregorian Year is the standard calendar year as defined by the Gregorian calendar, the civil calendar used worldwide since 1582 and the default fiscal-year basis for any Salesforce organization that has not configured a Custom Fiscal Year. In Salesforce, a Gregorian-year-based fiscal year runs January 1 through December 31, with quarters Q1 (Jan-Mar), Q2 (Apr-Jun), Q3 (Jul-Sep), and Q4 (Oct-Dec). Date math inside formulas, reports, forecasts, and dashboards all default to Gregorian year arithmetic. Salesforce explicitly calls out Gregorian Year as the alternative to Standard Fiscal Year (which uses a customizable start month while still aligning to four-quarter calendar weeks) and Custom Fiscal Year (which lets admins define arbitrary period structures). When an org uses a Gregorian fiscal year, the YEAR() formula function, the THIS_FISCAL_YEAR report filter, and the Collaborative Forecasts period grid all snap to January 1 as the first day of the year. Switching from Gregorian to a custom fiscal year is a one-way change with significant downstream impact and is rarely undertaken lightly.

Grounding is the practice of injecting authoritative source data into a generative AI prompt at runtime, so the model produces its response from that data rather than from training memory. In Salesforce, grounding means a Prompt Builder template pulls record data, related records, knowledge articles, files, or Data Cloud entities into the prompt before the foundation model sees it. The model still generates the response with its language ability, but the facts come from the customer's org, not from the internet text the model trained on. Grounding is the strongest single mitigation against hallucination. A well-grounded prompt drops the rate of fabricated answers from the 20 to 30 percent typical of ungrounded responses down to single digits for narrow tasks. Salesforce calls the runtime version dynamic grounding because the data is fetched per request, not baked into the template. The grounding step happens inside the Einstein Trust Layer, after PII masking and before the call out to the foundation model. Without grounding, every customer-facing GenAI feature is guessing.

A Group in Salesforce is a named collection of users, used as a single addressable unit for sharing records, granting permissions, queuing work, and routing automation. The platform supports three types of groups: Public Groups (admin-defined, available to share rules and sharing-button assignments), Personal Groups (user-defined, available only to the user who created them), and Roles + Subordinates (an automatically-managed virtual group based on the role hierarchy). Chatter also introduces a separate Chatter Group concept used for collaboration feeds, which is a different object and not the same as the Public Group described here. Public Groups are the workhorse: admins create them under Setup, Public Groups, add member users by username, role, or role + subordinates, and reference the group from sharing rules, record-level sharing, queues, list views, and email alerts. Groups can be nested (a group can include another group as a member), which lets admins build reusable user collections without re-listing the same users in every sharing rule. The Group standard object exposes the membership via SOQL, making automation and bulk audit straightforward.

A Group Member in Salesforce is a row in the GroupMember object that links a user, role, or other group to a Public Group, Queue, or other group container. Each GroupMember row represents one membership relationship: GroupId points to the parent group, UserOrGroupId points to the included user or sub-group. The object is the platform's central registry of group composition, queryable through SOQL and editable through Setup, Data Loader, and APIs. Group membership underpins much of the access control model. Public Groups grant folder access, list view sharing, queue ownership, and manual record sharing. Roles and the role hierarchy use a similar but distinct membership concept. Understanding the GroupMember object is the path to programmatic membership management: bulk-adding users to a group through Data Loader, automating membership based on a custom field, or auditing who is in which group across the org.

A Group Task in Salesforce is a single task assigned to multiple users at once. Salesforce creates one Task record per assignee, all linked to the same parent record (the related Account, Contact, Opportunity, or other object), so each user sees the task on their own My Tasks list and can complete it independently. The feature lets a sales manager assign one follow-up call to an entire account team, or a service supervisor assign a quality-check task to a queue of agents, without manually creating a separate Task record for each user. Group Task creation lives behind the Assign To Multiple Users checkbox on the standard Task creation modal. Once checked, the user picker accepts users, queues, public groups, role members, and role-plus-subordinates members. Salesforce expands the selection into individual Task records server-side. Subsequent updates (status, comments, attachments) apply only to the user''s own copy of the task; closing one user''s task does not close the others. The feature is invaluable for team-based work but adds a Task row per assignee, which can balloon Task volume on large teams.

A Guest User in Salesforce is the unauthenticated user account that anonymous, public traffic uses when interacting with a Salesforce Experience Cloud site, a Site.com site, a public-facing Visualforce page, or a public Flow. Every Experience Cloud site (and the older Site.com sites) has a Guest User record automatically created when the site is published. Visitors who land on the site without logging in operate under that Guest User''s profile and field-level security. The Guest User is therefore the security boundary between the public internet and any Salesforce data the site exposes. Salesforce treats the Guest User as a special user type with a dedicated User License (Guest User License) and a profile (Guest User Profile) that admins configure carefully. Object access, field-level security, sharing rules, and Apex with-sharing behavior all evaluate against this profile when a guest visitor takes an action on the site. Hardening the Guest User has become one of the most critical security tasks in any Experience Cloud rollout, because a misconfigured Guest profile has been the root cause of several public Salesforce data exposures.

The Guest User Sharing Rule Access Report is a Salesforce Setup tool that audits which records are accessible to the guest user (the unauthenticated user serving Experience Cloud sites, Sites, and public Communities) through sharing rules. The report surfaces every active sharing rule that grants access to the guest user role or to any group containing the guest user, helping administrators identify unintended public exposure of sensitive data. The tool was introduced as part of Salesforce's 2020 guest user security tightening initiative, after several high-profile breaches involving guest user records. The report is critical because guest user access has historically been one of the most common sources of accidental data exposure. A sharing rule that looks reasonable for internal users may inadvertently grant unauthenticated visitors access to customer data when the sharing target includes the guest user role. The report makes the audit tractable: rather than reviewing every sharing rule across every object manually, an administrator runs the report and sees a focused list of guest-user-relevant rules.

Guided Slack Setup is the Salesforce wizard-style configuration tool that walks admins through the end-to-end installation and connection of the Salesforce-Slack integration. Instead of navigating multiple Setup pages and coordinating with Slack admins manually, Guided Slack Setup presents a step-by-step flow: install apps in Slack, connect the workspace to Salesforce, map users, configure channels for records, validate the integration health. It is the on-ramp for new Slack-Salesforce deployments and the most reliable way to avoid the half-configured pitfalls that plague manual installations. The guide lives under Setup, Quick Find, Guided Slack Setup. Each step has clear prerequisites, validation checks, and rollback paths if something fails. Most steps require coordination with the Slack workspace admin; the guide handles the handoff with deep links into Slack and explicit instructions for what the Slack admin needs to do. For greenfield orgs adding Slack integration, this is the recommended starting point. For orgs that already have a partial integration, the guide is still useful as a verification tool to catch missing pieces.