#Salesforce Admin373 debatiendo

Hi everyone,

I would appreciate some architectural guidance on a Salesforce security requirement.

We need to restrict Sales users from exporting or extracting company-wide financial/reporting data, while they must continue using Salesforce normally, including the Salesforce Mobile App.

Our initial approach was to remove the API Enabled

permission from their corresponding Permission Set Group to prevent API-based extraction tools such as Data Loader or spreadsheet connectors. 

Howeever, I would like to confirm with you, if API Enabled is also required for the Salesforce Mobile App, which Sales users need to use.

Therefore, my questions are:

1. Is removing API Enabled an appropriate approach for preventing data extraction in this scenario, or would this have unintended consequences beyond the intended restriction?
2. What would be the recommended Salesforce architecture to restrict API-based data extraction for Inside Sales while keeping access to the Salesforce Mobile App?
3. Would API Access Control / Connected App allowlisting be a better approach, for example allowing Salesforce Mobile while restricting other API clients?
4. Are there other Salesforce permissions or security controls that should be considered specifically for preventing report/data export without disabling API access entirely?

The business requirement is specifically to restrict data extraction

, not to prevent Sales users from using Salesforce Mobile or other approved Salesforce functionality. 

The focus is on:

• Reports: No creating, editing, cloning, or exporting.
• Dashboards: No access to restricted Turnover dashboards.
• Subscriptions: Prevent receiving Reports/Dashboards via email.
• List Views: Prevent export/print as an extraction method.
• Folder Sharing: Prevent indirect access to restricted Reports/Dashboards.

Any guidance or documentation from Salesforce would be greatly appreciated. 

Hi everyone,

I'm working on a Revenue Cloud implementation with two sandboxes (both refreshed from the same production org, at different times). In Sandbox A, activating an Order correctly creates Asset records from the OrderItems. In Sandbox B, the exact same flow (Quote → Contract → Order → Activate) leaves the Order in Status = 'Activated' with zero errors, but no Asset is ever created — and querying Asset in that sandbox returns 0 records, period, in its entire history.

What I've already ruled out (identical between both sandboxes):

• RevenueManagementSettings, OrderSettings (all flags match, including enableEnhancedCommerceOrders=true, enableAutoAddDerivedAsset=true)
• PermissionSetLicense for Revenue Cloud User / Fulfillment User / Billing / Business Rules Engine — all Active
• Extended ContextDefinition mapping for Order/OrderItem vs Quote/QuoteLineItem — byte-for-byte identical counts
• No custom Apex triggers or Flows on Order in either org — it's the pure standard "Activate" action
• No AsyncApexJob/BackgroundOperation errors around the activation — nothing seems to even attempt the asset generation step
• TransactionProcessingType: the broken sandbox had zero records while the working one had one marked default (Business Rules Engine). I created a matching record via Tooling API, but the issue persists.

Has anyone run into a case where Asset-Based Order Management (or whatever gates Order→Asset generation) is silently disabled at the org level in a way that doesn't show up in any Settings metadata, Tooling API object, or PermissionSetLicense? Is there a one-time, irreversible enablement step (like "Enable Contract, Asset, and Subscription Management") that a sandbox refresh could leave off even when everything else looks provisioned?

Any pointers on where else to look (or whether this needs a Support case) would be hugely appreciated — this is blocking QA testing for a client go-live. 

Hello Trailblazers,

I am facing a login loop issue with a System Administrator profile when trying to access the Salesforce Mobile App on an iOS device (iPhone), and I would appreciate your insights.

1. I can log in into the desktop version perfectly using Windows Hello PIN as a registered Built-In Authenticator (Passkey).
2. When trying to log into the Salesforce Mobile App on iOS, after entering the Username and Password, the app forces a Passkey verification.
3. The native iOS is still prompting me to use a passkey and there is no chance to choose another verification option. Since the passkey was created locally via Windows Hello, the iPhone cannot resolve it, leading to a dead-end with no option to bypass or cancel.

What I tried so far:

• I disconnected the Built-In Authenticator from the User's Advanced Details via desktop Setup.
• Upon trying to log in again on the mobile app, it bypasses the old key but immediately demands the creation of a new Passkey.
• If I attempt to use a Temporary Verification Code, the login attempt is blocked beforehand by the following error message: 
  "Problem Verifying Your Identity. To log in, you need both a higher access level and an identity verification method. Contact your administrator to gain login access."

Context & Constraints:

• This is a production environment, so I cannot modify global organization settings (such as changing Session Security Levels or altering My Domain mobile browser behaviors) without a formal change control process. I need a solution targeted either at the user level or understanding why the Mobile API triggers this specific high-assurance restriction for this profile.

Has anyone encountered this specific behavior where the Mobile App demands a High Assurance MFA method that blocks the login completely before allowing alternative verification? Any workarounds at the user/permission set level would be highly appreciated.

Thank you in advance! 

Hi everyone,

I need an architectural sanity check on a security requirement. I want to avoid hitting platform limits down the road and would appreciate some feedback on whether this can be safely achieved using Schedule-Triggered Flows or whether Scheduled Batch Apex would be required.

Context

• We are changing the Organization-Wide Defaults (OWD) of the standard Quote object from Controlled by Parent to Private.
• We receive an integration feed from an external system that creates or updates up to approximately 80 Quotes per Account per day. Quotes can also be created manually in Salesforce.
• Quotes contain two custom Account lookups: Sold-To and Bill-To.
• We have both Quotes with and without Opportunities.

Requirement

• The Account Owner of the Sold-To Account and the Account Owner of the Bill-To Account must have Read-Only access to the related Quote.
• When the Account Owner changes, access to the related Quotes must be updated accordingly, including removing the previous owner's access and granting access to the new owner.
• The required access is managed through QuoteShare records with RowCause = Manual.

Architectural Question

Given the expected Quote volume and the need to automate the insertion and cleanup of QuoteShare records following Account ownership changes:

• Is this approach feasible using a standard Schedule-Triggered Flow, or would Scheduled Batch Apex be required to ensure scalability and avoid governor limits?
• What would be the cleanest architectural pattern for handling the cleanup and creation of Manual QuoteShare records when Account ownership changes?

Thanks for your guidance!

Hi everyone,

I have a question regarding the “Create Quotes without Opportunities” feature and a potential future requirement involving Orders.

After enabling the “Create Quotes without Opportunities” feature, Salesforce automatically provides the QuoteAccountId field on the Quote object. For Quotes created without an Opportunity, the Account relationship is stored in QuoteAccountId, while the standard AccountId is not populated.

Would it be technically possible to populate the standard AccountId field with the value from QuoteAccountId

for Quotes created without an Opportunity?. 

The reason for considering this is that Orders will be used in the future, and the standard Account relationship may be required for the Order process.

Would populating AccountId = QuoteAccountId be a supported and recommended approach, or are there any Salesforce limitations or implications we should consider when working with Quotes without Opportunities? or any workaround?.

Thanks for your guidance! 

Hi, we recently identified two challenges related to email attachments sent from Salesforce and would like to understand how others are handling similar situations.

     When an employee sends an email to a customer with an attachment, the file is also automatically uploaded to our Experience Cloud site. However, attachments larger than 35 MB are processed through Content Delivery, which generates a

     We also face email delivery issues with large attachments. Many email providers, including Outlook, enforce attachment size limits of around 25 MB. As a result, emails containing attachments between 25 MB and 35 MB may

• Do you use alternative file-sharing solutions?
• How do you prevent users from sending attachments that may exceed recipient limits?
• Do you have mechanisms to notify users when an email fails due to attachment size?

We'd be interested to hear about your best practices and any Salesforce-native or third-party solutions you've implemented.