The Fiscal Year in Salesforce is configured to start in January, which is the default calendar year rather than the company's actual April-to-March fiscal year. The fix is to go to Setup, search for Fiscal Year, set the Fiscal Year Starts In field to April, and verify the Fiscal Year Name Based On setting is correct for how the company names its years. Before saving, it is critical to communicate to all stakeholders that this change will immediately affect every existing report using fiscal-period relative filters like This FY, Last FQ, or Current Quarter, since those filters will now reflect the corrected April-to-March range rather than the previous January-to-December range, meaning the numbers shown will change visibly the next time those reports are run.

Basic Multiple Currencies allows amounts to be entered in different currencies and converts them to the corporate currency using the current exchange rate at the time the report is run. This means historical records show different converted values every time exchange rates are updated, making historical analysis inaccurate. Advanced Currency Management, or ACM, solves this by using dated exchange rates, locking the conversion rate to the rate that was active when the record was created or last modified, so historical data stays consistent regardless of future rate changes. ACM should be recommended for any organization that needs accurate historical pipeline analysis, revenue reporting by period, or forecasting that compares different time periods, which is most global businesses operating with currency-sensitive revenue reporting. The caveat is that both decisions are irreversible once enabled, and ACM has a known limitation with roll-up summary fields on custom objects that should be tested before production enablement.

These are two completely different problems caused by two completely different settings. The meeting reminders firing at wrong times is a Time Zone problem — the user's Time Zone setting on their user record does not match their actual location, causing Salesforce to display and calculate datetime values in the wrong offset from UTC. To diagnose, go to Setup, Users, open that user's record, and check the Time Zone field. The date format appearing wrong, for example showing MM/DD/YYYY when the user expects DD/MM/YYYY, is a Locale problem — the Locale on the user's record is set to English (United States) rather than English (India) or whichever locale uses the user's expected date format. To diagnose, check the Locale field on the same user record. Both settings are on the user record but control completely independent aspects of the user experience and are fixed separately.

My Domain is a security feature for three specific reasons beyond branding. First, it enables the option to prevent login from the generic login.salesforce.com URL, meaning all authentication must go through the organization's specific domain, which prevents attackers from attempting to bypass SSO or MFA requirements by using generic Salesforce login pages. Second, it is the technical prerequisite for SAML-based Single Sign-On with identity providers like Okta or Azure AD, which is itself a major security improvement over username and password authentication alone. Third, it is required for enforcing organization-specific login policies and authentication flows via Login Flows, which can add additional verification steps before granting access. Without My Domain, none of these capabilities are possible, which is why Salesforce made it mandatory for all orgs starting in Spring 2021.

With Business Hours correctly configured and referenced by the Escalation Rule, Salesforce will calculate 4 business hours starting from when the case was created. The business day ends at 5 PM Friday, meaning only 30 minutes of the 4-hour SLA window elapses on Friday. The remaining 3.5 business hours carry over to the next business day, which is 9 AM Monday assuming Saturday and Sunday are non-working days. 3.5 hours after 9 AM Monday is 12:30 PM Monday, so the escalation should fire at 12:30 PM Monday. This is only possible if the Escalation Rule is configured to use the Business Hours record, and the Business Hours record correctly excludes Saturday and Sunday. If Business Hours are not configured or not referenced by the Escalation Rule, the system would calculate 4 hours from 4:30 PM Friday and fire the escalation at 8:30 PM Friday, completely ignoring non-working hours.

Org-level Password Policies apply as the default to all users across the entire organization who do not have a more specific Profile-level policy overriding them. Profile-level Password Policies are set within individual Profiles and override the org default for all users assigned to that Profile. Profile-level policies are appropriate in several scenarios: first, when System Administrator profiles should have stricter requirements than regular users, such as shorter session timeouts, more complex passwords, or more frequent password changes, reflecting the higher risk of an admin account being compromised; second, when certain user groups like API-only integration users have no need for password expiration since they use token-based authentication and frequent password changes would break integrations; and third, when specific external or customer community users need different policies than internal employees. The general principle is that the org default handles the common case, and Profile-level overrides handle exceptions in either the stricter or more permissive direction.