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 stores a single suggestion, feature request, or piece of feedback that community members can read, vote on, and comment about. It is the central record behind the Ideas feature, the older feedback module that lets customers or employees post suggestions and rally support behind the ones they like most. Each Idea carries a title, a description, a category, an admin-defined status, and a running point score that drives where it ranks. Ideas sit inside zones, which group related suggestions for a specific audience or topic. Salesforce built its own public IdeaExchange on this model, where Trailblazers submit and vote on platform requests. The Ideas feature is now documented as a legacy Service feature, and Salesforce points new feedback projects toward the reimagined IdeaExchange with continuous voting and the RoadmapExchange. The standard Idea object still ships with the platform, so existing communities keep working.

An Idea Theme is an admin-curated topic in Salesforce Ideas that invites community members to post ideas about a specific question, problem, or product area. Instead of leaving the community to submit free-form suggestions across the whole product, a theme frames a prompt (such as a question about mobile experience or a new feature area) and collects the ideas that respond to it. Each theme can carry a title, a description with images or video, a category, a status, and the zone it belongs to. Themes live on the IdeaTheme standard object, and each contributing idea points back to its theme through the IdeaThemeId field on the Idea object. Idea Themes is a legacy feature. It still works in orgs that have it enabled, and Salesforce documents it under the legacy service features, but it is not the path Salesforce builds on for new feedback programs. Teams starting fresh today usually run idea collection inside an Experience Cloud site, or move to a dedicated feedback platform, rather than standing up classic Ideas with themes. If you already run themed campaigns on the IdeaTheme object, this entry explains how the pieces fit and what to keep in mind.

IdeaExchange is the official Salesforce community where customers, partners, and admins suggest new product features and vote on suggestions from other people. It lives at ideas.salesforce.com inside the Trailblazer Community, and Salesforce product managers read it, respond to it, and update each idea with a status that tells you where the request stands. The most popular and best-argued ideas feed directly into the Salesforce product roadmap. You reach IdeaExchange with the same Trailblazer ID you use for Trailhead and the Help portal. Anyone can browse ideas without signing in, but posting, voting, and commenting require a login. The platform is the working reference implementation of the Salesforce Ideas feature: the same crowdsourcing pattern customers can build in their own orgs, run here by Salesforce on its own platform.

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 that records every attempt your users make to verify their identity beyond a password. Each entry captures who attempted verification, what they were trying to do, the method used (such as Salesforce Authenticator, an email code, a one-time SMS code, or a security key), the source IP and geographic location, the date, and whether the attempt succeeded or failed. The same data is exposed as the VerificationHistory object in the API, which holds the past six months of attempts. You reach it under Setup by searching for Identity Verification History. The view is read only, so rows cannot be edited or deleted, only viewed and exported. Admins lean on it for two jobs. The first is incident response when a verification anomaly shows up. The second is adoption analysis: seeing how often people hit a verification prompt and which method they actually pick.

Identity Verification Settings is the Salesforce Setup page that controls how and when users prove who they are during login. It lives under Setup, in the Identity Verification node, and it applies to both your internal org and any Experience Cloud sites. From this one page an admin decides which verification methods are available, how one-time passcodes behave, whether email and SMS verification are allowed, and how device activation challenges work. The page does not authenticate anyone by itself. It sets the rules that the login pipeline reads when a sign-in looks unfamiliar, such as a new browser or an IP address Salesforce has not seen for that user. Get it right and people verify only when the risk warrants it. Get it wrong and you either prompt trusted users too often or let risky logins through with too little proof.

An Immediate Action is a type of Workflow Rule action in Salesforce that runs the moment the rule's criteria evaluate to true, inside the same transaction as the record save that triggered it. It sits on a Workflow Rule next to Time-Dependent Actions, which wait until a future point before they fire. The four action types you could attach as an Immediate Action were Field Update, Email Alert, Task, and Outbound Message. Workflow Rules are now legacy. Salesforce ended support for Workflow Rules and Process Builder on December 31, 2025, and the recommended replacement is a record-triggered flow built in Flow Builder. Existing rules keep running and you can still edit them, but no support or bug fixes are provided. The Immediate Action term still matters for orgs on legacy automation, for reading Migrate to Flow output, and for understanding older certification material, so it is worth knowing even though 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 a Salesforce feature that displays contextual help, announcements, and step-by-step walkthroughs directly inside Lightning Experience, so users learn in the moment without leaving the app. Admins build it in Setup under In-App Guidance, then target prompts and walkthroughs at specific Lightning pages and audiences chosen by profile or permission set. The feature comes in two building blocks. Prompts are single messages that appear once or on a schedule, and walkthroughs chain several prompts into a guided tour. Both can carry rich text, images, and links, and docked prompts can embed video. The goal is feature adoption: people are far more likely to read help that sits inside the screen they are already using than help that lives on a separate site.

An inbound call in Salesforce is a customer-initiated voice call that reaches a contact center through Salesforce-connected telephony, then surfaces inside the agent's console with the matching customer record and call data attached. The platform opens the related contact or case, records call details on a Voice Call object, and can fire automation when the call connects, transfers, or ends. An inbound call differs from an outbound call (the agent dials out) and from an internal call (agent to agent or agent to supervisor). Salesforce handles inbound voice mainly through Service Cloud Voice, which routes calls with Amazon Connect, with a certified partner telephony provider such as Cisco, Genesys, or NICE CXone, or with your own Amazon Connect instance under Bring Your Own Telephony. Older call centers used the Open CTI JavaScript framework so any vendor could embed a softphone. Open CTI is now deprecated and set to retire on February 28, 2028, with Service Cloud Voice as its replacement.

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 a Salesforce metric that ranks each Chatter user by how actively they post, comment, and earn engagement in the feed. Salesforce sorts users into three levels based on that activity: Top Influencers, Active Influencers, and Observers. The level shows on the user profile alongside activity statistics like number of posts, comments made, comments received, and likes or upvotes received on posts and comments. This is an older Chatter feature, most visible in Salesforce Classic, where the activity and influence panel sits under a person's profile photo. It still ships with Salesforce and the underlying influence rank is readable through the Chatter REST API and the UserInfluence object. Since acquiring Slack in 2021, Salesforce has steered new collaboration investment toward Slack, so most teams now treat Chatter Influence as a legacy reputation signal rather than something they actively tune.

An Initial Submission Action is an automated action that fires the moment a record first enters a Salesforce Approval Process. It runs when a user clicks Submit for Approval, the record meets the entry criteria, and the request is created, before the first approver ever sees it. The default Initial Submission Action locks the record so that nobody except approvers and administrators can edit it while the approval is pending. On top of that lock, an admin can attach field updates, email alerts, tasks, outbound messages, and flows. This phase belongs to the Classic Approval Process model, where Initial Submission Actions sit next to Final Approval Actions, Final Rejection Actions, and Recall Actions. Each phase is a hook into a different point of the approval lifecycle. Initial Submission is the one almost every process uses, because it sets the opening state of the record. A typical setup stamps an Approval Status field, emails the first approver, and posts a confirmation so the submitter and the reviewer see the same picture from the first second the request exists.

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 is a Salesforce Industries object that records a product or service a customer has acquired and that is now active, installed, or in service at a specific location. It connects the catalog product the customer bought to the account that owns it and to the place where it lives, such as a subscriber home, a meter, or a business site. The object is part of the Industries Common Data Model used by Communications Cloud, Media Cloud, and Energy and Utilities Cloud, where it tracks the modems, set-top boxes, service plans, and metered services a customer holds. Installed Product answers a simple operational question: what does this customer have right now, and where. It is usually created when an order is fulfilled, so it represents the live state of a subscription after activation. Industries teams use it for billing context, service troubleshooting, upgrades, and disconnects. It is close in spirit to the platform Asset object, and the two are often compared, but Installed Product carries the location and service framing that telco and utility processes depend on.

An instance in Salesforce is the single unit of infrastructure that runs a Salesforce organization. It is a cluster of application servers paired with a shared database, and every org is assigned to exactly one instance. That instance can be first-party infrastructure operated by Salesforce in its own data centers, or Hyperforce infrastructure hosted on Salesforce-managed AWS. Many customer orgs share one instance, with logical separation handled by the multitenant application layer. The instance determines where your data physically lives, when your org receives each seasonal release, and which maintenance windows apply to you. Salesforce gives every instance a short identifier, such as AP0 for a first-party instance in Japan or GBR1 for a Hyperforce instance in the United Kingdom. You can look up your own instance in Setup under Company Information, and you can track its health on the public Salesforce Trust status site.

An Insurance Policy in Salesforce is a record on the InsurancePolicy standard object, part of the Financial Services Cloud insurance data model. It represents one insurance contract between a carrier and a policyholder. The Salesforce documentation describes the object as representing the type of insurance policy, such as auto, home, life, or annuity. A single record holds the policy number, the policy type, the named insured, the policy owner, the effective and expiration dates, the premium, and the policy status. The object sits at the top of a small family of related records. Child and junction objects capture the insured items, the coverages and their limits, the people tied to the policy, and the transactions that change it over time. Carriers use this model for both personal lines (auto, home, life) and commercial lines (general liability, workers compensation, business owners). It replaced the older Asset-based approach that insurers relied on before Salesforce shipped a dedicated insurance object model.

An Integrated Development Environment (IDE) for Salesforce is the code editor that developers use to build, debug, test, and deploy Apex classes, triggers, Lightning Web Components, Aura components, Visualforce pages, and the rest of an org's metadata. The modern, officially supported choice is Visual Studio Code with the Salesforce Extension Pack, working on top of the Salesforce CLI. The same extensions also power Agentforce Vibes IDE, the browser-based environment that Salesforce launched as Code Builder. The IDE covers the full development loop. You create a project against a Dev Hub, pull and push source between local files and an org, run Apex tests, step through failures with the Apex Replay Debugger, and deploy through the Metadata API, change sets, or a pipeline. The tooling has converged on one stack, so Salesforce documentation now defaults to VS Code and the CLI for almost every developer task. Older editors such as the Eclipse-based Force.com IDE were retired, and the in-browser Developer Console still ships with every org for quick edits.

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 process in Salesforce OmniStudio that runs several actions in a single server call. It reads, transforms, and writes data across Salesforce objects and external systems without requiring user interaction, and returns one structured JSON response. Think of it as the OmniStudio equivalent of a stored procedure: a reusable backend that other components call rather than each rebuilding the same logic. Integration Procedures are part of the OmniStudio toolset alongside OmniScripts, FlexCards, and Data Mappers. An IP earns its place when a screen or process needs to bundle multiple operations together. A customer summary panel, for example, can call one Integration Procedure that queries Account, Contact, Service Contract, and open Cases at once, trims the result, and hands back a payload shaped for the front end. The same IP can be invoked from an OmniScript, a FlexCard, a Salesforce Flow, an Apex class, or an external REST call.

Integration testing in Salesforce is the practice of verifying that an org works correctly with the external systems it talks to, such as an ERP, a marketing platform, a billing engine, a payment gateway, or a data warehouse. These systems connect through REST or SOAP APIs, MuleSoft, ETL jobs, or Salesforce Connect. An integration test exercises the real data flow across those boundaries, confirming that a change on one side does not silently break the other. Integration testing sits one layer above Apex unit tests. Unit tests run in isolation and replace every external HTTP callout with a mock, so they never touch the outside world. Integration tests do the opposite. They run against live staging endpoints, or contract-tested stand-ins, and confirm that records, payloads, and identifiers move end to end the way a real user would expect.

An Integration User is a dedicated Salesforce user account that exists only to be the identity an external system authenticates as when it calls the Salesforce API. No human logs in as this account. It owns the OAuth credentials, the connected app authorization, and the run-as context that the outside system uses to read and write data. Salesforce ships a purpose-built license for these accounts called the Salesforce Integration user license, released in the Spring '22 (API version 242) release. That license is API-only, which means the account cannot sign in to any user interface. It pairs with the Minimum Access - API Only Integrations profile and the Salesforce API Integration permission set license, so you grant exactly the access each integration needs and nothing more.

Intelligent Appointment Management (IAM) is a Health Cloud feature that centralizes healthcare appointment scheduling into a single console. The console is powered by scheduling engines behind the scenes, and those engines can be Salesforce Scheduler, an Electronic Health Record (EHR) scheduling engine, or both at the same time. IAM aggregates the availability from those engines so that a scheduler or a patient sees every open slot in one place, instead of checking several disconnected systems. The point of IAM is to fix the fragmentation that makes healthcare scheduling slow. A call center agent can pull open slots from the EHR, book the appointment inside Salesforce, and push the booking back to the EHR so both systems stay in sync. Patients can self-schedule online, often as guest users, without a long data-entry form. The feature adds predictive guidance to surface times that are less likely to end in a no-show, and it sends reminders to keep attendance high.

An intelligent app is a business application with artificial intelligence built directly into the workflow, so the software predicts outcomes, recommends a next step, or generates content while a person works. Instead of only storing records and running fixed rules, an intelligent app learns from data and adapts as conditions change. In Salesforce, intelligent apps are the products and features that put AI inside the CRM. They run on the Einstein and Agentforce AI portfolio: predictive scoring, generative drafting and summaries, conversational copilots, and autonomous agents. The goal is the same in every case. Surface a useful recommendation or action right where the user already does their job, grounded in trusted Salesforce data.

An Intelligent Form Reader is a Salesforce Industries feature that uses optical character recognition (OCR) to pull structured data out of uploaded documents and write it onto Salesforce records. It reads PDFs and image files (JPG and PNG), recognizes the fields on a form, and maps each one to a field on a Salesforce object so a person does not have to retype it. The feature is powered by Amazon Textract and ships inside the Industries Clouds, where Salesforce first released it for Financial Services Cloud in Spring '21. Salesforce has since folded the capability into the broader Intelligent Document Reader, which extends the same OCR engine to more clouds. If you set this up today, you enable it under the Intelligent Document Reader settings, but the Form Reader name still appears in Financial Services Cloud and in the underlying APIs.

Intelligent Sales Settings is the Salesforce Setup page that turns on and configures Intelligent Sales, the image-recognition retail-execution capability inside Consumer Goods Cloud. Field reps use the Intelligent Sales mobile app to photograph a store shelf, and Einstein Object Detection compares that photo against the planned shelf layout to score on-shelf availability, product facings, and share of shelf. The Settings page is where an admin enables the feature, points it at the right object detection model, and grants reps and managers access through permission sets. It is not the same thing as the Einstein sales-AI features on core Sales Cloud, such as Einstein Activity Capture or Einstein Opportunity Scoring. Intelligent Sales belongs to the Consumer Goods Cloud product line and is aimed at consumer packaged goods companies whose reps visit physical stores. The setup ties together three moving parts: the licenses and permission sets that authorize use, the image model that reads shelf photos, and the store-visit data that field teams capture on the road.

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.

An Interaction Log is a Salesforce Classic console feature that gives agents a note-taking panel in the footer of a primary tab, then saves what they type as a Task on the record's Activity History related list. It appears in the Salesforce Console (the Service Console and the Sales Console), where an agent can jot notes during a call or chat without leaving the open record. The log always includes an "Enter your notes here..." field, and admins can add other editable Task fields such as a subject, a status, or a custom disposition picklist. This is older console plumbing, tied specifically to Salesforce Classic. Lightning Experience does not use Interaction Logs. The equivalent work in a Lightning console happens through the Activity Timeline and the Log a Call action, which write the same underlying Task records. If you are building a contact center today, treat the Interaction Log as legacy and plan note capture around Lightning activities instead.

An Interactive Voice Response (IVR) is the automated phone menu that greets inbound callers and routes them before a human agent picks up. The caller hears a recorded prompt, presses keypad digits or speaks a request, and either resolves the issue through self-service or lands in the right agent queue. In Salesforce, IVR is not a standalone product. It is delivered through Salesforce Voice (formerly Service Cloud Voice), where the telephony layer runs the menu and Salesforce supplies the data, screen pop, and Omni-Channel routing. Salesforce offers three telephony models, and each handles the IVR differently. With Amazon Connect, the IVR lives in Amazon Connect Flows. With Partner Telephony, a vendor such as Genesys or NICE runs the IVR through a managed package. With Partner Telephony from Amazon Connect, you bring your own Amazon Connect instance. Older deployments built IVR screen pops through Open CTI, but that framework reaches end of life on February 28, 2028, and Salesforce points customers to Salesforce Voice instead.

An Internal Call in Salesforce Service Cloud Voice is a voice conversation between two contact-center users, such as agent-to-agent, agent-to-supervisor, or agent-to-specialist, that stays inside the contact-center system instead of routing over the public phone network. The platform records these conversations on the VoiceCall object with CallType set to Internal, which separates them from Inbound calls (customer-initiated) and Outbound calls (agent-initiated to a customer). Internal Calls exist because service work often needs more than one person during a single customer interaction. A frontline rep consults a supervisor on a refund, brings in a billing specialist, or escalates to a higher tier while the customer stays on the line. Service Cloud Voice supports these rep-to-rep calls natively and writes a VoiceCall record for the internal leg so reports can see both the customer call and the consultation behind it.

An Interview in Salesforce is the runtime instance of a flow, the live execution that the platform spins up each time a flow runs. The flow definition you build in Flow Builder is the blueprint. The Interview is one specific run of that blueprint, with its own variable values, its own pointer to the current element, and its own running user. The full name in the documentation is Flow Interview, and the two terms are used interchangeably. Most interviews finish in milliseconds and never touch the database. The ones that pause stick around as rows in the FlowInterview standard object. A screen flow stopped at a Pause element, an autolaunched flow holding at a Wait, or a record-triggered flow with a scheduled path all leave a paused interview that an admin can find, resume, or delete under Setup. The same concept surfaces in Apex through the Flow.Interview class, which lets code launch a flow and read back its outputs.

An Invoice in Salesforce is a record that represents a billing document a company sends to a customer for products or services delivered. It captures what the customer owes, when payment is due, and the line-by-line breakdown of charges. The standard Invoice object stores the invoice number, the billing account, the invoice date, the due date, the total amount, tax, and a status such as Draft or Posted. Each Invoice has child Invoice Line records, and each Invoice Line traces back to a source charge like an Order Product or a billing schedule. The Invoice object is the native billing document in Revenue Cloud (the product line that absorbed the older Salesforce Billing package from the SteelBrick acquisition). It became a standard platform object available in API version 62.0 and later. Customers running Revenue Cloud generate invoices directly in Salesforce from activated orders. Many other orgs do not bill inside Salesforce at all. They integrate with an ERP or billing system such as NetSuite, SAP, or Stripe, then write the invoice and its payment status back into Salesforce so sales and service teams can see it.

An ISO Code in Salesforce is a short, standardized text value that follows an International Organization for Standardization specification. The platform uses three families of these codes. ISO 4217 gives every world currency a three-letter code such as USD, EUR, GBP, and JPY. ISO 3166 gives every country a two-letter code such as US, GB, and IN. A language and locale key such as en_US combines a two-character language code with an ISO 3166 country code to identify the user's language and regional formatting. The currency code is the one most admins meet first, because it drives the CurrencyIsoCode field that appears on every record once Multiple Currencies is turned on. Country codes feed the State and Country/Territory Picklists, and locale keys feed user language and the Translation Workbench. In each case Salesforce leans on the published standard so the same value means the same thing across reports, integrations, and customer-facing pages. Using the wrong variant (USA instead of US, or en instead of en_US) is a frequent source of broken data flows and silent display bugs.