#Sales Cloud194 discussing

Hi Pranav - yes, you can add the extra sites, and the pattern is one External Data Source per SharePoint site rather than reconfiguring the existing one. 

For each new site: 

1. Setup - External Data Sources - New. Type: 'Files Connect: Microsoft SharePoint Online'. Set the Site URL to that site collection's URL (a sub-site collection URL works too). 

2. Reuse your existing Authentication Provider - if the new sites are in the same Microsoft 365 tenant you do not need a new Azure AD app, just select the same Auth Provider in the lookup. (A different tenant would need its own Auth Provider.) OAuth is the only supported auth for SharePoint Online. 

3. Pick the Identity Type per data source: Named Principal (one shared service credential for everyone) or Per User (each user authenticates and inherits their own SharePoint permissions). 

4. Grant access: add each new External Data Source to the relevant Permission Sets/Profiles so users can see it. 

5. Save, then validate/sync - users will see the new site alongside the existing one under External sources in Files and can attach from it. 

So it is the same overall process, just a new External Data Source per site, sharing the Auth Provider wherever the tenant is the same. 

If this helps, please mark it as the Best Answer so it helps the next person - thanks :)

Good - since it is CPQ, that actually settles the design. Keep the Commercial (operating) account as the transactional account CPQ points its Quotes, Contracts and Orders to, and use the Legal Entity as a bill-to / contract-party lookup rather than moving the transactions onto it. 

The reason: CPQ hangs Contracts, Subscriptions and Assets off the account, and renewals, amendments and asset combination ('Combine Asset Quantities' is an Account field) all key off that same account. So for existing customers, if you migrate them onto a new Legal Entity account you risk breaking the renewal and contracted-price lineage. Safest pattern: apply the two record types from day one for net-new, and for existing accounts keep CPQ pointed at the Commercial account and just add the Legal Entity link. 

If this helps, please mark it as the Best Answer - thanks :)

Hi Rajan,

Based on your requirements, I think you'll be able to implement everything in Salesforce itself without using any free/paid tools.

e.g. You can use field properties to restrict the number of digits. Store country code-mobile number mapping in custom setting/custom metadata type and manipulate the number in flow/apex trigger. You can use picklist field for storing number type.

Please let me know if I'm missing anything.

Can you try this

IF(MOD(TODAY() - DATE(1900, 1, 6), 7) > 3, TODAY()+5, (IF(MOD(TODAY() - DATE(1900, 1, 6), 7) = 0, TODAY()+4, TODAY()+3)))

1900, 1, 6 was Saturday so in case you also create a task on Saturday then still the above formula will work bcoz then it will add 4 days to that 

 when Today is Monday, Tuesday then it will add 3 days, for Wednesday, Thursday, Friday it will add 5 days

Hope this helps,

If you want to import all existing emails from a PST file, the right method depends on where you want those emails to be imported. It is important for a large mailbox to keep the folder hierarchy, attachments and message properties rather than exporting individual emails. 

In case the destination requires a different email format, then you may try

for bulk PST conversion. It can process single PST or multiple PST files in a folder and export the mailbox data to MBOX, EML, EMLX, MSG, NSF, TGZ, HTML, MHTML, PDF and IMAP file formats. Conversion preserves folder and subfolder hierarchy, email properties and attachments. 

For a complete mailbox, batch processing is useful because all selected PST data can be handled together. The Date Range filter can also be left unused when the intention is to process the entire PST rather than a specific period. 

Before importing the complete mailbox, test a sample PST and verify the resulting folder structure and attachments.

Hey Midori, 

Your instinct is right, "Substitute email address for unverified domains" is exactly the intended solution for this scenario. Salesforce's own docs specifically call out Experience Cloud site users, consultants, and users with domains you can't verify as the use case for this setting. 

You don't need to add each client's domain to Authorized Email Domains, that's meant for domains you actually own and control (your own org-wide addresses, your company's sending domains). For client portal users on domains you have no ownership over, adding them individually isn't realistic or even the correct approach. 

With the substitute setting enabled, Salesforce sends on their behalf using a fallback address like

instead of failing the send outright. This keeps portal notifications, password resets, case updates, etc. flowing without needing DKIM or domain verification for every client. 

One thing to check: if your org does any inbound email filtering or client-side rules based on sender domain, this substitute address is different from the user's real domain, so loop in IT/networking if that could cause filtering issues on the client side. 

Reference: