#Sales Cloud107 diskutieren mit

To import all existing emails from a PST file, you can use Microsoft Outlook’s built-in Import/Export wizard. Open Outlook, go to File → Open & Export → Import/Export, select Import from another program or file, and choose Outlook Data File (.pst). Browse to your PST file, select the option to handle duplicate items, and choose the mailbox or folder where you want to import the emails. Click Finish to begin the process. 

If you need to import multiple PST files or migrate emails without relying on Outlook, you can use the

The gap you're hitting is that most tools only do Salesforce-to-Salesforce syncing, or syncing of files but not on a schedule.

CloudHQ the backup tier (not the sync tier you found) supports scheduled backups of Salesforce records as CSV plus files to SharePoint; check their backup product specifically.

Skyvia does Salesforce -> SharePoint Files export with scheduling, field selection, and filters.

DIY: Salesforce Data Export Service does weekly CSV exports; script out their Data Loader CLI to push those to SharePoint.

One caveat is that these are all exports, and not point-in-time backups; if they need to restore a deleted record back into Salesforce, check the restore path first.

For the SharePoint side specifically, the Kernel SharePoint Backup handles backup of SharePoint sites, document libraries, lists, version history, and permissions to local or NAS storage, with delta passes to skip already-saved items. It won't pull from Salesforce, but if the end goal is a clean, restorable copy of that data sitting in SharePoint, it covers that half.

@Roopa Sharma, This is a good area to learn early. Many orgs end up with documents in both systems, and the friction shows up exactly where you listed. Here is how each one tends to play out once a setup is live.  

1. Where the documents live - 
   • SharePoint as the home, with Salesforce records pointing to it. The usual choice when the company already runs on Microsoft 365.
   • Salesforce Files, when volumes are small and only CRM users need the documents. The Files related list is flat, with no folders per record.
2. Ways to connect the two
   • Files Connect (native): lets users browse, search and attach SharePoint files from Salesforce, but it does not create a folder per record.
   • Power Automate: a good fit if your team already builds on the Microsoft side. The trade-off is that the logic lives outside Salesforce, on a premium connector. 
   • AppExchange apps: compare them on four things. Does Flow create a folder when a record is created? Do uploads from the record go straight to SharePoint? Do SharePoint's own permissions still apply? Can you trial it in a sandbox first? 
3. Your questions, in practice - 
   • Folder structure: mirror your data model (Account, then Opportunities, then each opportunity), with the same subfolders on every record. Add the record ID to folder names so a rename never breaks a link. 
   • Metadata: tag files with SharePoint columns such as document type, status and record ID, instead of relying on folder names.
   •  Version control: let SharePoint's version history handle it, and avoid saving copies back into Salesforce. 
   • Security: SharePoint decides who can open a file. Salesforce sharing does not carry over to SharePoint on its own, so plan who updates access when an account changes owner.
   • User experience: users should reach a record's folder from the record page, without searching SharePoint.

If you go the AppExchange route, CloudFiles is one app that works this way with SharePoint. With its flow actions, each record gets a folder when it's created, and files are tagged as they arrive. Users open that folder from the record page, and SharePoint's permissions decide what each person can see. https://appexchange.salesforce.com/appxListingDetail?listingId=a0N4V00000Gh9uFUAR

Disclosure: I work at CloudFiles.

Thank you, @Matt Kelly

, that is very helpful. 

Your Close Date in the filter across the top of your screen shows October 1, 2026 - March 31, 2027, which might be why you're seeing Opportunities that are closed lost - because they have a "Close Date" within that date range. 

Are you looking for "Newly Created" Opportunities? or "Newly Closed" Opportunities? or both? or Opportunities that are only Staged as "New"?  What you are looking for will determine what fields you should use as filters for your report.   

Could you share a little bit more of what you're trying to accomplish with this report?

A custom build is a sound choice here. Sales Cloud has no native room-booking feature, and a couple of custom objects plus a flow cover this without another license. Here's a design that holds up well:

1) Data model

• Event Room (custom object): one record per room, with capacity, location and an Active checkbox.
• Room Booking (custom object): Room (lookup), Sales Rep (User lookup), Start and End (Date/Time), Status (Requested / Approved / Cancelled), plus the Trade Show and Account.
• Who can book: create a custom permission "Book Event Rooms" inside a permission set that the sales head assigns. Check it in the screen flow with $Permission. If authorization is per trade show, use a small junction object (Event + User) instead.

2) Preventing double bookings

Two bookings for the same room overlap when new Start < existing End AND new End > existing Start (ignore Cancelled ones).

• In the screen flow, run a Get Records with that filter before saving, and show a friendly message if anything comes back.
• Also enforce it on save. A screen-flow check alone can't stop two people saving the same slot at the same second. Use a before-save Apex trigger that locks the room (SELECT Id FROM Event_Room__c WHERE Id IN :roomIds FOR UPDATE), re-checks for overlaps, and calls addError(). A record-triggered flow with a Custom Error element works for the basic check, but the FOR UPDATE lock is what makes it race-proof.

3) Syncing to the rep's calendar

When a booking is Approved, have a record-triggered flow create a standard Event owned by the sales rep: same Start/End, Location = room name, Related To = the booking or account. Calendar sync then picks it up like any other Salesforce event. With Einstein Activity Capture, make sure event sync is turned on in a direction that sends Salesforce events to Outlook/Google. When a booking is cancelled or moved, update or delete that Event from the same flow.

4) The "Excel-like" view

Before building a full LWC, try the standard Lightning Calendar. You can create a calendar from any object with date fields (Calendar > New Calendar > Room Booking, Start/End fields, one list view per room) and share it with the team. If you still want a grid (rooms as rows, time slots as columns), build it as an LWC with lightning-datatable or a calendar library loaded as a static resource. Keep the save logic in the screen flow / Apex so the overlap rule lives in one place.

If you found this answer helpful, please mark it as helpful.

@Murali Pathivada This is a standard polymorphic relationship behavior on ContactPointAddress.ParentId, not something to design around as if it will always stay Account-only. Salesforce’s object reference lists ParentId as a polymorphic relationship that can refer to Account or Individual: https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/sforce_api_objects_contactpointaddress.htm

For long-term maintainability, the cleaner option is Option 1: add a dedicated custom lookup to Account.

Keep ParentId as the standard Salesforce parent relationship, but add something like Account__c on ContactPointAddress and populate it from ParentId when the parent is an Account. Then update validation rules, flows, reports, and formulas to use Account__r instead of trying to traverse the polymorphic Parent.

That gives you a stable relationship path for business logic. Salesforce supports cross-object validation/formula logic through normal lookup or master-detail relationships, which is exactly what the custom Account lookup gives you: 

Option 2 works technically, but it pushes too much logic into flows. Every validation that needs Account data would need a Get Records step, and validation rules that previously referenced Account fields would need to be rebuilt using Flow custom errors. Flow custom errors are useful, but they are heavier to maintain than a clear relationship field: 

You should:

Create Account__c lookup on ContactPointAddress 

Backfill it from existing records where ParentId points to an Account 

Use a before-save flow or Apex trigger to keep it in sync 

Add validation to require Account__c if your business says every delivery address must belong to an Account 

Move formulas and validation rules to Account__r 

Only use polymorphic ParentId where Salesforce requires it

For querying polymorphic relationships, SOQL supports polymorphic handling, but that does not solve the validation rule/formula maintainability problem: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/langCon_apex_SOQL_polymorphic_relationships.htm

Hi, it may be a tempporary issue as informed by Salesforce.https://help.salesforce.com/s/articleView?id=sales.dialer_limitations.htm&type=5