2.1 Company Information, Fiscal Year, Business Hours, and Locale

Admin baseline for org-wide settings

Start in Setup with Company Settings before changing user permissions, objects, automation, or applications. Company Information gives you a snapshot of the org that explains many later symptoms: edition, org ID, feature licenses, active user licenses, data and file storage, default locale, default language, default time zone, currency settings, and fiscal year configuration. On the exam and in real work, this page is often the difference between guessing and verifying.

A practical admin records the current state before changing anything. If a stakeholder says reports are wrong after a quarter close, do not start by rebuilding reports. Confirm the fiscal year, time zone, currency, and report filters. If a new region reports date confusion, compare the org default time zone with the affected users time zones and locales. If a team cannot onboard users, check license counts and feature licenses before assuming a profile or permission set issue.

Setup path map

Fiscal year configuration is a common scenario trap. Standard Fiscal Year works when the business uses ordinary calendar-aligned months and quarters, even if the fiscal year begins in a month other than January. Custom Fiscal Year supports irregular accounting patterns, such as 4-4-5 periods, but it adds complexity. Once a custom fiscal year is enabled, returning to a standard model is not a casual toggle. Treat the decision as a finance and reporting architecture decision.

Reports, dashboards, forecasts, quotas, and date filters depend on fiscal definitions. A sales leader may ask for last quarter pipeline, but that phrase only has meaning if Salesforce fiscal quarters match the finance calendar. If the fiscal year changes after records already exist, historical reporting can shift in ways that are hard for users to interpret. The safer workflow is to document the finance calendar, test report filters in a sandbox or Trailhead Playground when possible, and get signoff from finance and sales operations before production updates.

Business Hours and Holidays are equally practical. They are not just display settings. Service features can calculate elapsed time, pause time outside coverage, and evaluate milestones against the chosen business hours. A case due in 8 business hours means something very different for a weekday support queue, a 24 by 7 premium queue, and a regional queue that observes local holidays. If the business sells different support plans, the admin may need multiple business hours records and clear assignment logic.

A clean practice exercise is to create two business hour schedules in a Developer Edition org: Standard Support and Premium Support. Add a holiday to Standard Support only. Then create or inspect cases that use each support path and explain how response timing should differ. Even without building a full entitlement model, the exercise teaches why business hours are operational data. The trap is assuming one org-wide calendar can serve every support commitment.

Locale and language settings deserve the same care. Locale affects formats such as dates, numbers, names, and addresses. Language affects labels and translated UI text when translations are available. Time zone affects how date and time values display to users. A user in London and a user in California can view the same timestamp differently without any data corruption. Admin judgment means distinguishing a display issue from a stored data issue.

Currency settings can also appear in configuration scenarios. In a single-currency org, the corporate currency is straightforward. In a multi-currency org, currency behavior affects records, reports, forecasts, and integrations. Do not enable multi-currency simply because one user wants to type a different symbol. Confirm business requirements, data model impact, historical conversion needs, and reporting expectations first.

Change checklist

• Capture the current Company Information values, especially org ID, default locale, default time zone, fiscal year, currency, and license counts.
• Identify the business owner for the setting, such as finance for fiscal year or support operations for business hours.
• Test downstream features that consume the setting, including reports, dashboards, escalations, milestones, integrations, and user onboarding.
• Communicate what will change for end users, what will not change, and when the change takes effect.
• Keep a rollback or correction plan, even when the setting itself cannot be reversed cleanly.

The exam angle is usually scenario judgment, not memorizing every field on the page. If the question mentions wrong quarters, look at fiscal year before changing report types. If the question mentions case response time calculated through weekends, inspect Business Hours and Holidays before editing automation. If the question mentions date display differences by region, compare user locale and time zone before opening a data quality project. Setup navigation matters because the first page you choose reveals whether you understand the platform boundary.