Salesforce terms starting with I

Icons in Salesforce are the visual identifiers that appear next to objects, tabs, list views, and actions throughout the Lightning Experience UI. The platform uses the Lightning Design System (SLDS) icon library, a curated set of several hundred SVG icons covering objects, utilities, actions, statuses, and standard concepts. Each icon has a name (account, opportunity, custom_1, custom_55) and a category (Standard, Custom, Action, Utility, Doctype). Administrators choose an icon for each custom object and custom tab through the Object Manager. Beyond customization, icons matter for usability. Users navigate primarily by visual recognition: the tab bar, the App Launcher, and list views all rely on icons to distinguish similar-named items quickly. Picking distinctive icons for custom objects pays dividends in user adoption, while leaving custom objects on the default placeholder icon produces UI clutter that slows daily work. The platform offers a Custom icon range (Custom_1 through Custom_100) specifically for custom objects, plus the ability to use any Standard icon when the meaning fits.

An ID in Salesforce is the platform's unique identifier for every record, sObject, metadata component, and configuration item. Each ID is a string in one of two formats: 15-character case-sensitive or 18-character case-insensitive, with the 18-character version including a 3-character checksum that makes the ID safe to handle in case-insensitive systems like Excel and certain database tools. The first three characters of the ID identify the sObject type: 001 for Account, 003 for Contact, 006 for Opportunity, 500 for Case, and a unique prefix per object including custom objects. Every API call, SOQL query result, and URL path uses IDs. They appear in the record URL, in lookup fields, in EmailMessage relationships, in audit trails. Understanding the ID format saves countless debugging hours: when an integration fails because an ID was truncated, when a CSV import lookup fails because of case sensitivity, when an admin needs to query "all records of type X" using the prefix filter. IDs are the platform's connective tissue, and fluency with their structure is one of the markers of an experienced Salesforce practitioner.

An Idea in Salesforce is a standard object that captures a suggestion, feature request, product enhancement, or piece of feedback contributed by a community member. Ideas are the core record type in Salesforce Ideas, the feature-feedback module that lets internal employees or external customers submit suggestions, vote on others, and watch ideas accumulate community support over time. Each idea has a title, a detailed body, a status, a category, and a running vote tally that drives the Most Popular ranking. Ideas live on the Idea standard object alongside IdeaComment for replies, Vote for up-votes and down-votes, and Community for the container community that scopes the ideas. The product was the foundation of Salesforce''s own IdeaExchange (where customers submit Salesforce platform requests that influence the product roadmap), and many enterprise communities use Ideas to gather customer or employee feedback. Salesforce has signaled IdeaExchange Reimagined as the modern direction, but the standard Idea object and the legacy Ideas feature still ship with the platform.

Idea Themes are admin-curated topical containers in Salesforce Ideas that group ideas around a strategic prompt, campaign, or product question. A theme reads like a question (How should we improve our mobile experience? or What new features would help your daily workflow?), and community members submit ideas in response to the theme rather than as free-form suggestions. The theme has its own page, its own ideas list, and its own start and end dates that scope when contributions are accepted. The feature exists because free-form Ideas communities tend to drift. Without a strategic prompt, the community contributes random suggestions that may or may not align with the product roadmap. Themes refocus the community on the questions the product team actually needs answered, while still letting community members shape the conversation. Themes are stored on the IdeaTheme standard object with a child relationship to Idea, letting reports tie idea throughput to specific themes and measure campaign-level engagement.

IdeaExchange is Salesforce''s public community for customer-facing feature requests on the Salesforce platform itself, hosted at ideas.salesforce.com (and increasingly at the IdeaExchange Reimagined experience inside the Trailblazer Community). Salesforce customers, partners, and admins submit ideas for new Salesforce features, vote on existing ideas, and watch Salesforce product managers respond with status updates that ultimately drive the roadmap. The community has shaped many of the platform features customers use today, from Lightning Experience improvements to Flow Builder capabilities to Hyperforce data residency. IdeaExchange is the canonical reference implementation of Salesforce Ideas. The same Idea standard object, Vote object, and theme model that powers IdeaExchange ships with every Salesforce org for customers to build their own Ideas communities. Salesforce has been progressively migrating IdeaExchange to the IdeaExchange Reimagined platform, which adds tighter roadmap-integration, structured prioritization (Most Voted vs. Most Recent vs. Coming Soon), and Salesforce product-manager attribution on every status update. Both the legacy and modern IdeaExchange continue to drive Salesforce''s product roadmap.

An Identity Provider is the role in a Single Sign-On relationship that authenticates the user and asserts their identity to other applications. In Salesforce terms, the platform can act as either an Identity Provider (it authenticates users for external applications) or a Service Provider (it accepts identity assertions from an external IdP like Okta, Microsoft Entra, Google Workspace, or Ping Identity). Most enterprise Salesforce deployments configure an external IdP for workforce SSO so users log in once and access Salesforce alongside Slack, Workday, and other SaaS apps. The standards behind Identity Provider relationships are SAML 2.0 (the older XML-based protocol) and OpenID Connect / OAuth 2.0 (the modern JSON-based protocol). Salesforce supports both as IdP and as SP. SAML dominates legacy enterprise SSO; OIDC dominates new integrations and consumer-facing identity. Configuring an Identity Provider connection involves exchanging certificates, configuring entity IDs, mapping user attributes from the IdP to Salesforce User fields, and testing the handshake. Done correctly, users see seamless SSO; done incorrectly, users hit cryptic authentication errors that look mysterious to debug.

The Identity Provider Event Log is the Salesforce Setup view that surfaces audit events related to the org acting as an Identity Provider for federated SSO scenarios. When Salesforce is configured as the SAML or OpenID Connect Identity Provider for downstream applications (or for other Salesforce orgs through Environment Hub), every authentication event produces a log entry: successful logins, failed logins, error responses, and configuration changes. The log is the canonical audit artifact for SSO-related security investigations. The log appears in Setup > Identity > Identity Provider Event Log. Each entry captures the timestamp, the relying party (the application or org that requested authentication), the user, the event type, and any error message or status code. Retention follows the standard Salesforce log retention windows; for longer-horizon audit, export to a SIEM through Event Monitoring or scheduled extract. The log is read-only for administrators; events cannot be deleted or modified through the standard UI.

Identity Resolution is the Salesforce Data Cloud process that merges multiple source records representing the same real-world person into one canonical Individual profile. The same human might appear as a Salesforce Contact, a Marketing Cloud Subscriber, an external loyalty member, and a Service Cloud Case Contact across four different systems. Identity Resolution applies match rules (exact email, normalized phone, fuzzy name plus date of birth) to identify which source records belong to the same person and assigns them a shared Unified Individual ID. The output is one Unified Individual record per real person, with links back to every source record that contributed to the match. Downstream Customer 360 features (segmentation, calculated insights, activations, prompt grounding) operate on the unified Individual rather than on the fragmented source records. Identity Resolution is what makes Customer 360 actually a 360-degree view; without it, the platform has the same person three times and counts them as three customers.

Identity Verification is the Salesforce platform's mechanism for confirming that the person logging in is actually the user the account belongs to, going beyond just username and password. The platform requires identity verification under several scenarios: first login from a new device or IP address, login from a previously unverified location, and any access that risk signals flag as suspicious. The verification step typically asks the user to enter a code sent to their registered email or phone, or to use the Salesforce Authenticator app or a registered FIDO security key. The feature is the platform's adaptive authentication layer, separate from but related to mandatory Multi-Factor Authentication (MFA). MFA is the prompt that requires a second factor on every login (or every session). Identity Verification is the prompt that appears when the platform detects something different about this specific login attempt. Both work together: an org with mandatory MFA may still trigger Identity Verification challenges when a known user logs in from a brand-new device, because MFA satisfies one risk signal but device unfamiliarity is a different signal.

Identity Verification History is the Salesforce log capturing every identity verification attempt across the org. Each row records the user, the verification method used (email code, SMS code, Salesforce Authenticator push, FIDO security key), the device and IP address, the timestamp, and the success or failure status. The log is the audit artifact for verification activity, alongside Login History (which captures every login attempt) and Identity Provider Event Log (which captures SSO events when Salesforce is the IdP). The log appears under Setup > Identity > Identity Verification History. Retention follows standard Salesforce log retention; for longer horizons, Event Monitoring exports the data to an external SIEM. The log is read-only: events cannot be deleted or modified, only viewed and exported. Administrators use it for two main purposes: incident response when a verification-related anomaly arises, and adoption analytics to understand how often users encounter verification prompts and which methods they actually use.

Identity Verification Settings is the Salesforce Setup page that controls how identity verification behaves across the org: which verification methods are allowed, what triggers a verification prompt, how long verified devices remain trusted, and which user populations are subject to which rules. The page is the master control panel for the adaptive authentication layer that protects suspicious login attempts. Most settings have sensible defaults that suit standard B2B SaaS orgs; regulated industries (financial services, healthcare) typically tighten the defaults beyond standard. The settings affect every user in the org but interact with several other features: Login IP Ranges (per-profile IP allow-lists that skip verification), MFA enforcement (separate from but layered with verification), Network Access settings (the org-wide IP restrictions), and Connected App settings (for API-based access). Misconfiguration produces either users hitting verification too often (over-strict, productivity hit) or users not hitting verification often enough (under-strict, security risk). The page is the single control plane for tuning that balance.

An Immediate Action is the type of Workflow Rule action in Salesforce that fires as soon as the rule criteria evaluate to true, in the same transaction as the triggering DML. Immediate Actions sit on a Workflow Rule alongside Time-Dependent Actions, which delay until a future point. The two action types existed to give Workflow Rules the flexibility to handle both real-time updates (set a flag, send an email, update a field) and time-delayed escalations (warn the owner if no activity happens within 48 hours). Workflow Rules are end-of-life. Salesforce announced their retirement in 2026; the Migrate to Flow tool converts existing Workflow Rules (including their Immediate Actions) to record-triggered flows. Modern record-triggered flows handle Immediate-Action equivalents in the standard flow logic, with no separate concept needed. The Immediate Action term remains relevant for orgs still running legacy Workflow Rules, for cert exam history, and for understanding Migrate to Flow output, but no new automation should be designed around it.

Import Articles is the Salesforce Knowledge feature that bulk-loads knowledge content from external systems into the Salesforce Knowledge base. The Setup utility takes a CSV file plus a ZIP archive of attachments and creates Lightning Knowledge articles with their titles, bodies, data category assignments, file attachments, and translation metadata in a single load operation. The feature is the standard migration path for orgs moving from a legacy knowledge management tool (Zendesk Help Center, ServiceNow Knowledge, Confluence, SharePoint, or a homegrown CMS) into Salesforce Knowledge. It supports the import of new articles, updates to existing articles, and translated versions of the same article in multiple languages. Successful imports require careful preparation of the source data, a valid configuration file describing the import, and pre-existing matching data categories, record types, and validation rules in the target org.

The Import Wizard is the Salesforce browser-based tool for loading data into the platform without writing code or installing Data Loader. It handles up to 50,000 records per import and supports a curated subset of standard and custom objects: Accounts and Contacts, Leads, Solutions, Campaign Members, Person Accounts, and most custom objects. The wizard is the standard onboarding tool for administrators who need to load data occasionally but do not want to learn Data Loader or build an integration. The wizard guides users through a fixed sequence: choose object, choose data source (CSV file), map source columns to Salesforce fields, decide on duplicate matching behavior, preview, and import. It runs in the user's browser, so the file is uploaded directly to Salesforce without intermediate storage. The wizard cannot do everything Data Loader can (no upserts on Tasks, no scheduled imports, no API-level error handling), but for one-time loads under 50,000 records on a supported object, it is faster to use and harder to misuse than Data Loader.

In-App Guidance is the Salesforce feature that surfaces contextual help, walkthroughs, and prompts directly inside the Lightning Experience UI, without sending users to a separate help site. Admins create prompts (single-step pop-ups) and walkthroughs (multi-step tours) under Setup, In-App Guidance, target them at specific pages or components, and choose the audience by profile, permission set, or user-level criteria. Users see the guidance as floating cards or pinned panels in the relevant context. The feature exists because users abandon any process that requires leaving the app to read documentation. In-App Guidance fixes the problem by putting the documentation inside the moment of use. A new sales rep on their first opportunity sees a walkthrough explaining the required fields. A service agent loading a new console layout sees a prompt explaining what changed. The guidance can include rich text, images, video embeds, and links to deeper help. Adoption of new features improves dramatically when guidance is in-app instead of off-app.

An Inbound Call in Salesforce refers to a customer-initiated voice call that arrives at a contact center routed through Salesforce-aware telephony, primarily Service Cloud Voice. The call is delivered to an agent inside the Salesforce console, with the platform automatically opening the matching customer record, attaching call metadata, and triggering downstream automation when the call connects, when it transfers, and when it ends. Inbound Call differs from an Outbound Call (agent-initiated) and from an Internal Call (agent-to-agent or agent-to-supervisor within the contact center). Salesforce supports inbound voice through several products. Service Cloud Voice is the native option, where calls flow through Amazon Connect (the default partner), Service Cloud Voice for Partner Telephony (Cisco, Genesys, NICE CXone, others), or Bring Your Own Telephony with a custom integration. The Open CTI framework underpins all of them; it exposes JavaScript APIs that any telephony vendor can implement to render their softphone inside the Salesforce console and respond to inbound call events.

An Inbound Change Set is a Salesforce change set that arrives in the current org from a connected source org, awaiting deployment. Change sets are the legacy mechanism for moving metadata between connected orgs (sandbox to production, sandbox to sandbox). On the source side, an admin builds an Outbound Change Set listing the components to migrate; on the target side, the same change set appears as Inbound, where an admin reviews the contents and clicks Deploy to apply. Inbound Change Sets sit in the target org's Setup > Deploy > Inbound Change Sets list until they are deployed or deleted. Each entry shows the source org, the change set name, the upload date, and the deployment status. The list is the target-side counterpart to Outbound Change Sets; together they form a paired deployment workflow that predates SFDX and is still supported in modern orgs. Many teams have moved to SFDX deployments because they offer source control and metadata API tooling, but change sets remain in use for small declarative deployments and orgs without dev-ops infrastructure.

An indirect lookup relationship is a Salesforce field on an external object that points to a standard or custom Salesforce object record, keyed on a custom external ID field marked Unique on the Salesforce side. It is the reverse direction of an external lookup: instead of a Salesforce record reaching out to an external system, an external object reaches into Salesforce and joins on a business identifier the user controls. The pattern lets external data brought in through Salesforce Connect resolve back to Salesforce master records without forcing the external system to know the 15-character Salesforce ID. A product master in SAP can carry its own SKU, and the SKU sits on the Salesforce Product record as a unique external ID. The indirect lookup field on the external object then joins on SKU, surfacing the related Salesforce Product alongside the external transaction data.

Industries Cloud Einstein is the Salesforce label for the AI features bundled inside the industry-specific Salesforce clouds: Health Cloud, Financial Services Cloud, Manufacturing Cloud, Consumer Goods Cloud, Communications Cloud, Energy & Utilities Cloud, and the others in the Industries portfolio. The features include patient risk scoring, financial recommendation engines, demand forecasting, route optimization, and dozens of other capabilities optimized for the data models and workflows of each industry. Most are pre-built; some are configurable through industry-specific Setup pages. The defining property is that Industries Cloud Einstein features ship with industry-specific data models and assumptions baked in. A patient risk score in Health Cloud understands the difference between an active patient and a discharged one without configuration. A wealth tier prediction in Financial Services Cloud knows what a household relationship is. These industry assumptions are why the features perform well out of the box on industry-cloud orgs and why they would not transfer cleanly to a standard Sales or Service Cloud setup.

Chatter Influence is the score that Salesforce calculates for each Chatter user based on their posting and engagement activity inside the Chatter feed. The influence ranking distinguishes Top Influencers, Active Influencers, and Observers; users move between buckets as their posts, comments, likes, and being-liked counts accumulate over time. The score is visible on the Chatter Influence tab on the user profile and (in some org configurations) on the user''s record header. The feature was Salesforce''s answer to making Chatter feel like a social network with reputation signals. Top Influencers contribute more, get more engagement, and become discoverable through the People tab and the Find People search. Active Influencers are mid-tier contributors; Observers consume content without posting. Salesforce derives influence with a weighted formula that combines post count, comment count, likes received, and recency of activity. The exact weights are not published; Salesforce treats them as proprietary.

Initial Submission Actions are the actions executed at the moment a record enters a Salesforce Approval Process for the first time. They fire when a user clicks Submit for Approval and the record meets the entry criteria, before the first approver receives the request. The action set typically includes Field Updates (mark the record as Submitted, lock related fields), Email Alerts (notify the submitter and approver), Task creation (queue a follow-up for the submitter), and Outbound Messages (notify external systems that an approval is in progress). Initial Submission Actions sit alongside Final Approval Actions, Final Rejection Actions, and Recall Actions in the Approval Process configuration. The four phases give admins a complete lifecycle hook into the approval flow. Initial Submission is the most commonly used; it sets up the state of the record (locking it via the Locks the Record for Editing flag, posting to Chatter, sending a confirmation email) so the submitter and the approver see consistent information from the first moment the request is alive.

An Initialization Vector (IV) is a random or unique value combined with an encryption key during the encryption process to ensure that encrypting the same plaintext twice produces different ciphertexts. The IV is one of the foundational concepts of modern symmetric encryption: without it, identical inputs would always produce identical ciphertexts, allowing attackers to identify patterns in encrypted data. The IV is not secret (it is often stored alongside the ciphertext) but it must be unique per encryption operation under the same key. In Salesforce Shield Platform Encryption, IV handling distinguishes the two available encryption schemes. Probabilistic encryption uses a fresh random IV per record, providing the strongest security but breaking SOQL filters and sorts on the encrypted field. Deterministic encryption uses a derived IV based on the plaintext, producing the same ciphertext for the same plaintext, which allows SOQL equality matches but reveals which records share the same value. The IV choice is the central trade-off in Shield: filterability versus pattern resistance.

Installed Packages is the Salesforce Setup-area page that lists every managed and unmanaged package currently installed in the org. The page shows the package name, namespace prefix, publisher, version, installation date, and whether the package is licensed (for paid AppExchange products) or limited (for trial installations). It is the single source of truth for "what third-party code is running in this org," critical for security audits, license management, and dependency tracking. Setup, Installed Packages is where admins manage the full lifecycle of each package: viewing the contents (objects, fields, Apex classes shipped by the package), uninstalling, upgrading, viewing dependencies, and configuring post-install setup. Packages from the AppExchange (DocuSign, Conga, Geopointe, Apsona) install here. Internal first-party packages built by the org's developer team using Salesforce DX unlocked packages also appear here. The Installed Packages page is the operational counterpart to the AppExchange listing experience; AppExchange is the storefront, Installed Packages is the running inventory.

An Installed Product in Salesforce is a record representing a physical or licensed item that a customer has acquired and that is installed, activated, or deployed at a specific location. The concept appears in Field Service (the InstalledProduct standard object lets technicians know what equipment lives at a service location), in Manufacturing Cloud, in Communications Cloud (where Installed Products track the network equipment a telco customer uses), and in the broader Salesforce Industries Common Data Model. Installed Products link a Product (the catalog item) to an Account (the customer) and often to a specific Service Territory or Location. The object exists because Service Cloud''s base Asset object historically conflated several concepts: the item itself, where it lives, when it was installed, who maintains it, and what work has been done on it. Installed Product cleans this up by separating the installed instance (location, install date, serial number, status) from the catalog product. Field Service technicians use it to plan maintenance routes; Manufacturing Cloud uses it to track customer-deployed equipment; Communications Cloud uses it for telco inventory. The newer Industries data model treats InstalledProduct as a first-class object, distinct from Asset.

An Instance in Salesforce is the physical pod (a cluster of servers and a shared database) where a Salesforce organization runs. Historically, instances had identifiers like NA1, NA12, EU3, AP2 (continent + sequence number), and the URL of a Salesforce org reflected its instance (na1.salesforce.com, eu3.salesforce.com). Multiple customer orgs share a single instance, with logical separation enforced at the application layer. Salesforce maintenance windows, release schedules, and outage notifications are scoped to an instance. With Hyperforce, the instance concept has shifted. Hyperforce orgs run on public-cloud regions (AWS US-East, AWS EU-West, AWS Asia-Pacific) instead of named pods. The URL switches to the org''s My Domain (companyname.my.salesforce.com), and the legacy NAxx hostnames become redirects. Despite the shift, the instance term still appears in admin contexts: status.salesforce.com tracks instance-level uptime; release-preview decisions still reference instance pods for pre-Hyperforce orgs; and the User Interface API exposes an Instance Name field for diagnostic and integration purposes.

An Insurance Policy in Salesforce Financial Services Cloud is a record on the InsurancePolicy standard object representing the active contract between an insurer and a policyholder. The object holds the policy number, the issuing carrier (typically an Account), the policyholder (a Contact or Person Account), the policy type (Auto, Home, Life, Health, Commercial), the effective and expiration dates, the premium amount, and the coverage details. Insurance Policy is the centerpiece of the Financial Services Cloud Insurance data model, with child objects for InsurancePolicyAsset (insured items), InsurancePolicyCoverage (coverage limits), InsuranceClaim (claims filed), and InsurancePolicyParticipant (named insureds, beneficiaries, agents). The object replaces the Asset-based and custom-object approaches insurance carriers used before Salesforce released the Insurance data model. The Financial Services Cloud Insurance package layers on Account record types (Policyholder, Carrier, Broker), Lightning components (Policy Summary, Coverage Grid), and Flow templates (Quote-to-Policy, Renewal). The combined model supports both personal lines (auto, home, life) and commercial lines (workers compensation, business owners, general liability), with field-level extensions per product line.

An Integrated Development Environment (IDE) for Salesforce is the code editor that developers use to build, debug, and deploy Apex classes, triggers, Visualforce pages, Lightning Web Components, Aura Components, and metadata configurations to a Salesforce org. Modern Salesforce IDE work centers on Visual Studio Code with the Salesforce Extensions Pack, paired with the Salesforce CLI (sf) for command-line operations. Earlier generations of the Salesforce IDE included the Force.com IDE (Eclipse-based, retired in 2018) and the in-browser Developer Console (still maintained but rarely the primary editor). The IDE handles the full development loop: project creation against a Dev Hub, source pulling and pushing between local files and the org, debugging via Apex Replay Debugger, testing via the Apex Test Runner integration, and metadata deployment via Change Sets, Metadata API, or DevOps Center. The IDE choice has converged: Visual Studio Code with Salesforce Extensions is now the supported, official tool, and Salesforce documentation defaults to it for every developer workflow. Custom IDEs (IntelliJ with Illuminated Cloud, custom SFDX wrappers) still exist and are popular with certain developer communities.

An Integration Definition in Salesforce is a reusable configuration record that describes how the org connects to a specific external system, what operations are available, and how data flows between the two. It sits in Setup under Integrations and serves as the central registry for declarative connections used by Flow, Apex, Agentforce, and Data Cloud. Rather than scattering connection details, authentication, and schema across multiple Apex classes or Flow elements, an Integration Definition bundles them into a single addressable artifact. Each definition holds a named connection, one or more operations (often imported from an OpenAPI specification), and optional mapping rules. Once defined, the same integration can be referenced by any number of automations without duplicating the underlying configuration.

An Integration Procedure (often abbreviated IP) is a declarative server-side orchestration in Salesforce OmniStudio (formerly Vlocity), used to fetch, transform, and write data across Salesforce objects and external systems without writing Apex. Integration Procedures combine actions (DataRaptor read or write, HTTP callout, Remote Action, Set Values, Conditional Block) into a sequence that runs server-side and returns a structured response. They are the OmniStudio equivalent of a stored procedure: callable from OmniScripts, FlexCards, Lightning components, REST APIs, and flows. Integration Procedures shine when an Industries Cloud implementation needs to bundle multiple operations into a single server call. A common pattern is loading a customer summary screen: one Integration Procedure queries Account, Contact, Service Contract, and Open Cases in a single call, transforms the result, and returns a JSON payload tailored to the front-end OmniScript. Without the IP, the OmniScript would need multiple round-trips to Salesforce. IPs reduce traffic, enforce server-side logic, and provide a reusable backend for multiple front-end consumers.

Integration Testing in Salesforce is the practice of verifying that the Salesforce org works correctly with the external systems it talks to: ERP, marketing automation, billing, payment gateways, data warehouses, and any other application connected via API, MuleSoft, ETL, or Salesforce Connect. Integration tests differ from Apex unit tests, which exercise code in isolation with mocked callouts. Integration tests use the actual external endpoints (or contract-tested stand-ins) and confirm that the full data flow works end-to-end across system boundaries. The discipline is required because Salesforce orgs rarely live alone. A typical enterprise org pushes data to a finance system, pulls leads from a marketing tool, syncs cases with a customer service desk, and exchanges files with a data warehouse. Every release introduces risk that one of these integrations breaks: a deprecated API field, a renamed object, a tightened sharing rule, an unexpected payload change. Integration testing catches these failures before production deploy, typically by running a regression suite against a sandbox connected to a staging copy of every external system.

An Integration User in Salesforce is a dedicated user account whose sole purpose is to serve as the identity that external systems authenticate as when calling Salesforce APIs. The integration user owns the OAuth refresh token, the JWT certificate, or the Connected App credentials used by the external system. Salesforce introduced the Salesforce Integration license in 2023 as the official license type for these users, replacing the prior practice of dedicating a full standard user license to an integration account. The Integration User License is restricted: it allows access only through APIs, not through the standard UI; it has a limited subset of standard objects (Account, Contact, Opportunity, Case, Lead, Task, Event, plus selected others); and it is priced at a fraction of a standard Sales or Service license. The license is the recommended approach for any non-human integration identity. Existing orgs running integrations under standard licenses can swap to Integration User licenses to free up the standard seats, with limited migration work required.

Intelligent Appointment Management (IAM) is the Salesforce Industries feature that combines scheduling logic, availability optimization, and customer-facing self-service to handle appointment booking at scale. It sits inside Field Service and inside the Industries Clouds (Financial Services Cloud, Health Cloud, Public Sector Solutions), depending on the use case. IAM lets the platform suggest optimal appointment times based on resource availability, customer preferences, location, skill, and SLA constraints, and exposes the booking experience through Lightning components, Experience Cloud sites, and Salesforce Scheduler. The product replaces the manual back-and-forth (phone call, email exchange, scheduling tool round-trip) with a self-service experience: the customer picks a time from a curated list of available slots, the platform reserves the slot, and downstream automation populates the calendar of the assigned resource. The intelligence layer goes beyond simple calendar availability: it factors in resource skill, location proximity, customer history, SLA windows, and even predictive load balancing to surface the right options first.

Intelligent Apps in Salesforce refers to the family of AI-powered, vertical-specific applications that Salesforce ships under the Einstein and Industries Cloud brands. The term covers Einstein-enhanced versions of standard products (Einstein Lead Scoring, Einstein Opportunity Scoring, Einstein Bots, Einstein for Service) and the AI-native Industries apps (Einstein for Health Cloud, Einstein for Financial Services Cloud, Einstein for Manufacturing Cloud). Each Intelligent App layers machine learning, generative AI, or predictive scoring on top of standard Salesforce data to surface recommendations and automate work. With the launch of Einstein 1 Platform and the Atlas Reasoning Engine in 2024-2025, the Intelligent Apps category expanded to include Agentforce-powered agents, Prompt Builder templates, and Copilot capabilities embedded in every Lightning page. The earlier set of point-solution Intelligent Apps (Einstein Lead Scoring as a standalone feature) is being consolidated into a unified Einstein AI stack, but the term Intelligent Apps remains in Salesforce''s product marketing as the umbrella for the AI-enhanced application portfolio.

Intelligent Form Reader (IFR) is the Salesforce feature that uses OCR and machine learning to extract structured data from scanned forms, PDFs, and images uploaded to Salesforce, mapping the extracted fields to Salesforce records automatically. Built on Amazon Textract under the covers, IFR is licensed inside the Industries Clouds (Financial Services Cloud, Health Cloud, Public Sector Solutions) where heavy form-based data intake is the norm. A common use case is a customer uploading a paper application or insurance claim; IFR extracts the fields and pre-populates the relevant Salesforce record before a human reviews. The feature exists because forms (paper applications, signed claims, scanned identity documents) are still the predominant data-intake channel in regulated industries. Manual transcription of these forms is slow, error-prone, and a leading source of operational cost. IFR replaces transcription with automated extraction, leaving humans to review the AI-extracted output rather than type the whole form. Combined with OmniStudio for the front-end workflow, IFR can power a fully-automated paper-to-Salesforce pipeline.

Intelligent Sales Settings is the Salesforce Setup page that controls the AI-driven sales features layered on Sales Cloud: Einstein Activity Capture, Einstein Conversation Insights, Einstein Opportunity Scoring, Einstein Forecasting, and similar capabilities. The page is the master control for opt-in to these features, the data sharing they require, and the user populations they apply to. Each feature has its own deeper configuration screen, but Intelligent Sales Settings is the on-off and scope page that ties them together. The features generally require additional licensing beyond base Sales Cloud (Sales Cloud Einstein, Inbox, or Sales Engagement). Some are bundled with specific editions; others are add-ons. Confirm licensing before enabling because the settings page lets you toggle features that may not actually be provisioned, producing confusing post-toggle behavior where the feature appears active but produces no output. The page also surfaces data-privacy controls: which user activity is shared, which conversations are recorded, and how AI-generated insights are surfaced to managers.

An intent is the classification primitive used by Salesforce Einstein Bots and the legacy Einstein Intent Service to recognize what a user is trying to do in a conversation. Each intent has a name, a description, and a set of training phrases (typically 20 to 100 per intent) that an NLP model learns from. When a user message arrives at a bot, the model computes a confidence score for every defined intent and returns the highest as the picked intent. The dialog or action wired to that intent runs next. Intent classification is the foundation of every traditional conversational bot. It tells the bot "the user wants to check their order status" or "the user is asking about a refund" so the bot can route to the correct dialog. In Agentforce, the equivalent concept is the agent topic, which uses natural-language classification descriptions instead of training phrase lists. The intent model is deterministic and trainable on closed examples; the topic classification model is LLM-driven and more flexible at the cost of less direct control.

The Interaction Log is the Service Cloud Console feature that lets agents capture notes during a customer interaction (a call, chat, or email session) and save them as a Task tied to the active record. It surfaces as a panel in the Service Console that opens with a single click while the agent is on a call or chatting. The panel includes a rich-text editor for the notes, a status picker, and a save button that creates a Task with the captured content linked back to the Account, Contact, Case, and the related call or chat record. Interaction Log exists because agents need a low-friction way to document what happened during a customer interaction without leaving the active conversation. Without it, agents would either skip note-taking (losing the audit trail) or break their attention to navigate to a new Task screen (slowing the conversation). The panel sits inline with the call or chat UI, capturing notes throughout the interaction and saving the full log when the conversation ends. Modern Service Cloud Voice augments this with automatic transcription that pre-fills the log, but the manual notes still matter for context the AI cannot capture.

Interactive Voice Response (IVR) is the automated voice-menu system that greets inbound callers before connecting them to a human agent. The caller hears a recorded prompt (Press 1 for sales, 2 for service), uses keypad input or spoken responses to navigate, and either resolves their need through self-service or gets routed to the right agent. In Salesforce, IVR is delivered through Service Cloud Voice (on top of Amazon Connect), through partner-telephony integrations (Genesys, NICE CXone, Cisco), or through customer-supplied IVR systems that integrate via Open CTI. The IVR is the first interaction layer a customer experiences with a contact center, and it sets the tone for the whole engagement. A well-designed IVR routes the caller to the right resource in 20-30 seconds with minimal frustration. A badly designed one bounces callers through nested menus, fails to recognize voice input, and produces a measurable spike in call abandonment. Salesforce''s integration with Amazon Connect and the AI-driven Einstein Bots increasingly replaces fixed IVR menus with natural-language conversational IVR, which understands free-form caller requests and routes accordingly.

An Internal Call in Salesforce Service Cloud Voice is a voice conversation between two contact-center users (agent-to-agent, agent-to-supervisor, agent-to-specialist) that happens inside the contact center system rather than going through the public phone network. Internal Calls support warm transfers, consultative escalations, and supervisor coaching, all without disconnecting the customer or requiring the originating agent to re-establish the call. The Voice Call standard object marks these conversations with CallType = Internal, distinguishing them from Inbound (customer-initiated) and Outbound (agent-initiated to a customer) calls. The feature exists because contact-center work routinely requires multi-agent collaboration during a customer interaction. A frontline agent needs to consult with a supervisor on a refund decision; a service rep needs to bring in a billing specialist; a tier-1 agent escalates to tier-2 while keeping the customer on the line. Internal Calls handle all of these without dropping the customer call. Modern Service Cloud Voice on Amazon Connect supports internal calls natively, with Salesforce capturing both the customer call and the internal consultation as linked Voice Call records.

An Interview in Salesforce is the runtime instance of a flow, alternately known as a Flow Interview. The term shows up across documentation in two contexts: as a synonym for Flow Interview (each run of a flow definition), and occasionally as a synonym for a candidate interview process tracked in Salesforce-based applicant tracking systems. The Flow Interview meaning is the primary one. Each time a record-triggered flow fires on a save, a screen flow launches from a user click, or an autolaunched flow runs from Apex, the platform creates an Interview that tracks the variables, current element, and running user for that specific execution. Most interviews finish in milliseconds and never appear in the database. Paused screen flows, scheduled-path waits, and Pause-element-paused interviews persist as rows in the FlowInterview standard object. Admins can monitor paused interviews under Setup, Paused and Waiting Interviews, resume them on behalf of the user, or delete them when the underlying scenario no longer applies. The Interview term is also visible in the Apex Flow class (Flow.Interview) and the Bulk API job model where each running job has its own interview-like execution context.

Intraday Management is the Salesforce Service Cloud Workforce Engagement feature that lets contact-center supervisors monitor and adjust agent schedules, queue load, and SLA risk in real time during the operating day. It surfaces a live operational dashboard with current call volume, agent presence states, queue depth, expected wait times, and any breaches of the planned schedule. Supervisors use the dashboard to make tactical decisions: move agents between queues, send agents to break, escalate help to a slammed channel, or call in part-time staff to handle an unexpected spike. The feature is part of the broader Salesforce Workforce Engagement (WFE) product family that includes Forecast Management (long-term capacity planning) and Schedule Management (agent shift assignment). Intraday Management is the in-the-moment layer that reacts to actual demand versus the forecasted demand. When a planned schedule fails to predict reality (a viral product launch drives 3x normal call volume, a system outage spikes case volume), the supervisor uses Intraday Management to reallocate resources before the SLA breach becomes a customer-experience disaster.

An Invoice in Salesforce is a record representing a billing document sent to a customer for goods or services delivered. The platform supports invoices in several products: Salesforce Billing (now part of Revenue Cloud) for subscription-billing scenarios, Salesforce Order Management for B2C and B2B retail flows, Financial Services Cloud for advisor-billing scenarios, and Industries-specific implementations (Health Cloud patient billing, Communications Cloud subscriber billing). Each product layers its own data model on top of the standard Invoice and Invoice Line objects, but the core concept is the same: a periodic billing document driven by underlying Orders, Order Products, and pricing rules. The Invoice object stores the invoice number, the billing account, the invoice date, the due date, the total amount, the tax, and the status (Draft, Posted, Paid, Cancelled). Invoice Lines store the line-by-line breakdown linked to Order Products, Subscriptions, or other source records. Most enterprise Salesforce orgs do not generate the invoice itself in Salesforce; they integrate with an ERP or billing system (NetSuite, SAP, Workday, Stripe Billing) that produces the invoice and writes it back to Salesforce for visibility. Revenue Cloud customers do generate invoices natively in Salesforce.

ISO Code in Salesforce most commonly refers to the three-letter currency code defined by ISO 4217 (USD, EUR, GBP, JPY, INR) that the platform uses for multi-currency operations. It also refers to ISO 3166 country codes (US, GB, DE) used in address fields and to the ISO language codes (en_US, fr_FR, de_DE) used in user-language and translation contexts. In each case, Salesforce relies on the international standard to normalize text values across the platform, integrations, and customer-facing data. The currency ISO code is the most operationally important: it drives the currency picker on financial fields, the multi-currency conversion exchange rates, and the foreign-key relationships in DatedConversionRate, OpportunityCurrency, and any other multi-currency feature. Country and language codes drive user preferences, internationalization of content, and the Translation Workbench. Working with ISO codes correctly is the foundation of any global Salesforce deployment; using the wrong code (3-letter US instead of USA, or en instead of en_US) breaks integration data flows and produces silent display bugs.