Company settings are the org-wide identity values that anchor every record, every report, and every automation decision tied to time, money, or location. They are stored once at the tenant level and propagated to every user, every object that records a date or amount, and every component that displays a localized value. An administrator must understand which of these settings can be changed freely, which carry irreversible consequences, and which are inherited by user records only at creation time.
The business problem these settings solve is alignment between the Salesforce org and the legal entity that runs it. A Salesforce tenant might serve a holding company whose fiscal year does not align with the calendar, whose support desk runs on a four-day rotation, whose deals are negotiated in seven currencies, and whose users span four time zones. Without org-wide settings, every forecast would carry a different start date, every business-hours calculation would mismatch, every multi-currency report would show inconsistent totals, and every record would display in a different format. Company settings remove that drift by establishing the single source of truth that every other feature reads.
Company Information and Default Locale Defaults
Company Information stores the legal name of the organization, the primary contact, the org-wide default language, locale, time zone, and currency. The locale governs how dates, numbers, and names are formatted; the language governs which translated strings the platform renders; the time zone governs how times are stored and displayed. These three values are inherited by every newly created user record as a default, but they can be overridden per user. Changing the org-wide values does not retroactively rewrite values on existing user records.
The Company Information page also displays the org identifier, the edition, the used and remaining licenses by license type (Salesforce, Salesforce Platform, Customer Community, and so on), and the data and file storage usage. Administrators read this page to confirm available license counts before bulk-creating users and to confirm storage headroom before a bulk import. Storage values are refreshed asynchronously, so a recent import may not be reflected for several minutes.
💡 Exam Trap: Changing the org-wide default time zone, locale, or language on the Company Information page does NOT update the time zone, locale, or language on existing user records. Those values were copied to the user record at creation. To change them in bulk on existing users, use Data Loader or a permission-driven mass update, not the Company Information page.
Standard vs Custom Fiscal Year
The fiscal year setting controls how Salesforce groups dates for forecasts, opportunity reports, quotas, and the year-based grouping in standard report types. Two fiscal year models are available: a Standard Fiscal Year and a Custom Fiscal Year.
A Standard Fiscal Year follows the Gregorian calendar, with quarters of three calendar months each. The administrator picks the start month (for example, April for a fiscal year that runs April through March) and whether the fiscal year is named after its start or end calendar year. A Standard Fiscal Year is the right choice when the business reports on three-month quarters that begin on the first day of a calendar month.
A Custom Fiscal Year supports week-based patterns (typically 4-4-5, 4-5-4, or 5-4-4 week distributions across each quarter) and 52-53 week years used in retail. Custom Fiscal Year permits the administrator to define a period template once and roll it forward year by year. Custom Fiscal Year cannot be turned off after it is enabled, and forecasting features behave differently under custom periods.
⚠️ Anti-Pattern: Enabling Custom Fiscal Year as a precaution "in case we ever need it" without an active business requirement. The change is one-way; once Custom Fiscal Year is on, the org cannot return to a Standard Fiscal Year configuration. Several forecasting and quota features assume Standard Fiscal Year semantics and behave with reduced functionality under Custom periods.
Business Hours and Holidays
Business Hours define when a support team is open. A business hours record stores the per-weekday open and close times plus a time zone, and can be linked to a holiday list to suppress hours on closed days. Business Hours records are referenced by entitlement processes, case escalation rules, case milestones, and the Service Console, where they drive how long a case has been "open during business hours" rather than wall-clock open. The default business hours record applies when no specific record is referenced; additional records can be created for regional teams (Americas Support, EMEA Support, APAC Support) and selected per case.
A holiday record stores a date and a name, and is associated with one or more business hours records. A holiday can be a one-time event or set to recur annually. When a case escalation timer or a milestone calculation hits a holiday, the clock is paused for the duration of the holiday.
📊 Limit: Each org can store up to 1,000 business hours records and link any number of holidays to each. Each holiday can recur annually, but a single holiday record can be associated with multiple business hours records to avoid duplicating the same closed date for every team.
Currency Management: Single and Multi-Currency
The corporate currency is the currency the org reports in. In a single-currency org, every amount field is in the corporate currency, and the choice cannot be changed once records exist (because historical amounts would not be reinterpreted). In a multi-currency org, the corporate currency remains the reporting denominator and each user, each amount field, and each opportunity can be assigned a different active currency. The platform displays both the entered currency amount and the converted corporate currency amount on records and in reports.
Multi-currency must be requested from Salesforce Support to be enabled, and it cannot be disabled afterwards. Once enabled, each amount field stores the entered amount plus a currency ISO code, and the platform applies the active exchange rate at read time to compute the corporate-currency value.
Advanced Currency Management (also called dated exchange rates) layers a date range on each exchange rate so that an opportunity closed in a prior quarter is converted using the rate that applied during that quarter, not the rate that applies now. Without dated exchange rates, every historical record is re-valued whenever the rate table is updated, which distorts historical revenue reporting.
💡 Exam Trap: Activating a currency does not require dated exchange rates, but reporting on historical revenue across a rate change does. If the business asks "why did last quarter's number change when I updated the EUR rate yesterday?", the answer is that dated exchange rates have not been enabled, and the new rate is being applied retroactively to all historical EUR opportunities.
Currency model decision matrix
| Requirement | Single Currency | Multi-Currency without Dated Rates | Multi-Currency with Dated Exchange Rates |
|---|---|---|---|
| All deals in one currency, no foreign customers | Best fit | Adds complexity for no gain | Unnecessary |
| Sell in several currencies, real-time conversion to corporate currency | Not supported | Adequate for current quarter | Adequate plus historical accuracy |
| Need historical revenue to remain stable after rate change | Always stable | Will retroactively change | Best fit |
| Forecasting needs to roll up multi-currency pipeline | Not supported | Supported | Supported |
| Reversible | Reversible only before data exists | One-way enablement | One-way enablement |
Default Settings and Localization
Default settings include the org-wide default language, locale, time zone, and currency listed above, plus several behaviour defaults: the default lead owner (used when web-to-lead does not assign one), the default case owner (used when web-to-case does not assign one), the default activity reminder time, and several record-creation defaults. These defaults are read at runtime when a record arrives without an explicit value; setting them avoids null owners on inbound records.
The combination of locale, language, and time zone is the single most-asked configuration question in the user setup process. A user record in pt_BR locale, en_US language, and America/Sao_Paulo time zone displays English labels with Brazilian Portuguese number and date formatting, anchored to Sao Paulo time. The three settings are independent and must each be set deliberately.
🎯 Scenario: Acme Logistics opens a regional office in Mexico City. The administrator must decide whether to change the org-wide default time zone. The answer is no. The org-wide default reflects the headquarters; the regional team gets a different time zone on each new user record. Changing the org default would affect every future new user created in any region, which is rarely the intent.
Decision Anchor: Choose a Standard Fiscal Year when the business reports on three calendar-month quarters; choose a Custom Fiscal Year only when the business runs a 4-4-5 or 52-53 week retail calendar. Choose single currency when every customer pays in the corporate currency; choose multi-currency with dated exchange rates when historical revenue reports must remain stable after rate updates.