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 Salesforce is an HTTP request that uses the GET method to read data from a web resource. Salesforce both produces and consumes them. Apex code builds a GET callout to pull data from an external API, and the Salesforce REST API answers GET requests on its own endpoints to return records, query results, and org metadata as JSON. GET is the read-only verb of HTTP. It sends no body, so all input travels in the URL as the path and the query string. It is idempotent, meaning a repeated call returns the same result and changes nothing on the server. That safety is why GET is the default verb for most integrations, why intermediaries can cache its responses, and why it is the easiest callout to test and retry. The same per-org callout limits, timeout ceiling, and response size cap apply whether the verb is GET or anything else.

A getter method in Apex is the public accessor that hands the value of a class member back to whatever code asks for it. The classic shape is a private instance variable holding the data, plus a public method (or property accessor) that returns it without changing anything. Apex supports the Java-style getX() method form and the shorter property form with get and set blocks, and both compile to the same underlying method on the class. Getters show up most in Visualforce controllers, where a page expression like {!accountName} resolves to a getAccountName() method or an accountName property on the controller. They also appear in Lightning Web Component JavaScript, where a getter computes a value for the template, and behind @AuraEnabled Apex methods that feed data to components. A getter can return a plain field, or it can compute, lazy-load, or cache, which is where most of the design decisions live.

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 area of Salesforce Setup that controls how an org connects to Google Workspace for sales email and calendar work. It groups three things: the Gmail Integration itself (the Chrome extension and Google Workspace add-on that show Salesforce records inside Gmail), the capture engine that pulls emails and events into Salesforce (Einstein Activity Capture today, Lightning Sync in older orgs), and the per-user step that links each rep's Google account to Salesforce. This is where an admin switches on the org-wide capability, picks a sync configuration, and assigns the users who get it. It does not configure anything on the Google side. That work happens in the Google Admin console. From Salesforce, the integration is a capability flag, and the real data movement runs over OAuth tokens and the consent each user grants when they install the add-on.

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.

A Gregorian Year is the standard calendar year defined by the Gregorian calendar, the civil calendar that runs January 1 through December 31. In Salesforce it is the default fiscal-year basis for any organization that has not switched to a custom fiscal year. A new org starts on this setting, so its fiscal year, quarters, and fiscal-year report filters all line up with the natural calendar. Salesforce treats the Gregorian year as the foundation for its standard fiscal year, which the official documentation describes as one that follows the Gregorian calendar year but can start on the first day of any month you choose. When the start month is January, the fiscal year is fully Gregorian: Q1 covers January through March, Q2 April through June, Q3 July through September, and Q4 October through December. Date functions in formulas always read the Gregorian year regardless of how the fiscal year is set.

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 single record in the GroupMember object that links a user or another group to a parent group such as a Public Group or a Queue. Each row records one membership: the GroupId field points to the parent group, and the UserOrGroupId field points to the user or nested group that belongs to it. The object is the platform's registry of who is in which group, and it is queryable through SOQL and editable through Setup, Data Loader, and the APIs. Group membership feeds much of the sharing model. Public Groups grant folder access, list view visibility, queue ownership, and manual record sharing. Because a sharing rule or a manual share that targets a group reaches every member, the GroupMember object decides who actually receives that access. Knowing how the object behaves is the difference between clicking through members one at a time and managing membership in bulk with a script or a data file.

A Group Task in Salesforce is a single task you assign to more than one person at once, where Salesforce then creates a separate Task record for each individual recipient. You pick people, public groups, or queues in the Assigned To field on the New Task screen, and on save the platform expands that selection into one independent Task per user. Each recipient owns their own copy, sees it on their task list, and completes it without affecting anyone else. There is no shared multi-owner Task record behind the feature. Assigning to a ten-person public group produces ten Task rows, each with its own OwnerId. The multi-recipient option is only available when the task is first created. You cannot edit an existing task later to add a group or extra users, and you cannot reassign a task to multiple people after the fact. The behavior is built into the standard task creation interface, so there is no special object or button to learn.

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.