#Desktop Integration3 utenti parlano di questo argomento

Hi Maximo,

There are really two separate issues here: sending the emails through your company's Exchange/domain and getting those emails logged in Salesforce.

If your requirement is to send the messages through your company's Exchange server so the recipient sees your company domain, I'd look at the Salesforce email relay/integration options available for your Salesforce release rather than manually copying the emails to Outlook. That allows Salesforce-generated emails to be routed through your organization's mail server. 

For the logging side, if the emails are sent from Outlook, you'll need an Outlook/Salesforce integration or another synchronization process to associate the sent emails with the appropriate Contacts/records. That is preferable to manually importing hundreds of messages.

Given the 2012 timeframe of this question, the exact options depend heavily on your Salesforce edition and the Outlook/Exchange integration you're using. 

Hi, 

Choosing between LinkPoint Connect (LinkPoint360) and the native Salesforce for Outlook (SFO) depends heavily on your team's need for synchronization reliability versus budget. In 2012, while Salesforce for Outlook is free and native, third-party tools like LinkPoint often provided a much more stable and intuitive side-pane experience.

Here is a breakdown of how they compare to help you decide: 

1.Best for Robust Side-Pane Usability and Stability:LinkPoint Connect (Third-Party). 

LinkPoint Connect is a paid, third-party integration tool renowned for its advanced side-pane interface, which lets users view and manage Salesforce records directly inside Outlook without constantly switching tabs. It handles bi-directional syncing for contacts, calendar events, and tasks with significantly fewer sync conflict errors than native tools of the era. 

Users can view, create, and edit Salesforce records and attach emails directly from the Outlook sidebar seamlessly. 

2.Best for Zero-Cost Native Deployment:Salesforce for Outlook (Native). 

Salesforce for Outlook is the official, free plugin provided by Salesforce. It allows users to sync contacts, events, and tasks and offers a basic side panel to add emails to Salesforce. However, administrators frequently encounter performance overhead, database synchronization conflicts, and occasional client crashes in heavy corporate environments. 

Hi Lam,

When you implement Single Sign-On (SSO) using SAML, desktop clients like Connect for Outlook handle authentication through your identity provider (IdP) rather than requiring standard Salesforce passwords and security tokens.

Here is how the authentication flow works and how it bypasses the traditional password-plus-token requirement: 

1.Configuring the Connection URL:Custom Domain & Redirect. 

When setting up Connect for Outlook in an SSO-enabled environment, users configure the plugin to point to your organization's custom My Domain URL rather than

. When the client attempts to connect, Salesforce recognizes the host domain and redirects the authentication request directly to your Identity Provider (such as ADFS, Okta, or Azure AD). 

2.Handling Authentication Securely:Token Assertion. 

Instead of passing a plaintext username and password, the client uses an OAuth or browser-based flow where the user authenticates against your corporate IdP. Once verified, the IdP sends a cryptographically signed SAML assertion back to Salesforce over SSL. Salesforce validates this token and issues a session ID back to the Outlook plugin, completely removing the need for a security token or standard password.

Hi John, 

The native Salesforce for Outlook field mapping settings require a direct field-to-field pairing, meaning you cannot hardcode a static string value (like "Meeting") directly inside the configuration interface. The mapping tool expects a corresponding Outlook field rather than a fixed text string.

To ensure your "Type" field is populated correctly and your reports are accurate, you can implement an automated workaround on the Salesforce side: 

1.Map to an Available Outlook Field:Field Mapping. 

Map the Salesforce "Type" field to an existing or custom text field in Outlook (such as Categories or a user-defined field) so that users can input the value before syncing. You can verify success when data flows from that specific Outlook field into Salesforce upon synchronization. 

2.Use Salesforce Workflow Rules or Triggers:Automated Defaults. 

To bypass manual user input, let the events sync over and use a Salesforce Workflow Rule with a field update (or an Apex trigger) to automatically stamp the "Type" field based on criteria like subject keywords or the user profile. You can verify success when newly synced events automatically reflect the correct Type in your reports without manual intervention.

Hi Evan, 

The frustration with the shift from the old Outlook 2003 "opt-in" model to the newer "all-in" sync behavior in Outlook 2010 is a very common pain point for administrators trying to protect user privacy. 

By default, the official Salesforce for Outlook plugin handles synchronization broadly, and as you noted, the "Private" status checkbox on calendar items isn't always reliably respected depending on configuration and sync direction, creating a high risk of over-sharing personal data. 

To get back to a controlled model where items are only pushed over intentionally, you have a couple of solid pathways:

1.Configure Outlook Categories in Salesforce for Outlook:Category-Driven Filtering. 

You can configure the native Salesforce for Outlook settings to filter items by specific Outlook Categories rather than syncing everything blindly. By setting up sync configurations to only look for a designated category (like "Sync to Salesforce"), items remain private on your local machine until a user explicitly applies that category tag. You can verify success when un-tagged calendar entries and contacts stay local, while tagged items successfully populate in Salesforce. 

2.Leverage Category-Aware Integrations:Third-Party Add-Ins. 

If the native plugin's filtering constraints fall short for mobile users, enterprise-grade third-party integrations (such as Cirrus Insight or LinkPoint360) offer granular rule-based settings. These tools allow you to enforce strict domain blacklists, handle private event filters explicitly, and rely on manual side-panel log buttons rather than an automated all-inclusive sweep. You can verify success when users can seamlessly log only chosen communications directly from their inbox side-panel.

Hi J, Salesforce for Outlook can associate incoming emails with Salesforce records when it can identify a matching contact or related record, but it may not automatically associate the reply with a specific Request number/custom record.

If the Request is a custom object, you may need to use custom automation or Apex to associate the incoming email with the appropriate Request record based on the Request number in the subject/body. 

As for replying directly from Salesforce, that depends on how the email is stored and the Salesforce features available in your org. If you can share whether “Request” is a standard or custom object and how the original email is being sent, it would help determine the best approach. 

Hi Kari,

When using Salesforce for Outlook or standard event sync tools, fields from related parent records (like Opportunity details) don't automatically sync down into Outlook calendar descriptions by default.

Here is how you can pull those details over: 

1.Use a Flow or Trigger to Copy Details:Workflow Automation. 

Create a record-triggered flow or Apex trigger on the Event object that checks if the event is related to an Opportunity (WhatId starts with 006). If it is, query the parent Opportunity fields and append them into the Event's Description field. You can verify success when creating an event linked to an opportunity automatically populates the description box with opportunity details. 

2.Verify Outlook Sync Settings:Sync Configuration. 

Ensure your Salesforce for Outlook or Einstein Activity Capture configuration is set up to sync the Description and Subject fields bi-directionally or from Salesforce to Outlook. You can verify success when the synced calendar invite in Outlook displays the appended opportunity details.

Hi Jake,

The error indicates that the ContactTrigger is failing during the BeforeInsert operation because a required Name field is missing. 

The important part of the error is:

This usually means the trigger or related Salesforce configuration is trying to create a record without populating a required Name field. It may not necessarily mean that Salesforce is missing a field from Outlook. 

Please check the pba.ContactTrigger code and any related automation to see where the required Name value is being populated. Also verify the Salesforce for Outlook field mappings and the affected Outlook contact. 

If you can provide the ContactTrigger code and the relevant field mappings, more specific guidance can be provided.

Hi,

Since Chatter works through IE8 but Chatter Desktop reports that the network is offline, the issue is likely with how the desktop application is using the proxy rather than with your Salesforce login. 

I'd check the Windows 7 Internet/Proxy settings and confirm the proxy server, port, and authentication method are the same as those working in IE. If your company proxy requires authentication, the Chatter Desktop application may also need to be explicitly allowed through the proxy/firewall. 

Since you're using a VM for Windows XP and the same application works there, comparing the proxy/network settings between the XP and Windows 7 environments would be a good way to identify the difference. 

If it still doesn't connect after verifying the proxy settings, I'd provide the Chatter Desktop version, Windows 7 version (32/64-bit), and proxy authentication type to Salesforce Support.

Hi Rhonda, 

If you’re using the Salesforce for Outlook integration, the standard email composer generally only lets you send to the recipients exposed through the email fields (To/CC/BCC), unlike the older Outlook connector. 

If you need to send the same email to additional Salesforce Contacts and have the activity associated with them, you may need to add them as recipients in Outlook or use a custom solution/automation depending on the exact requirement. 

If you can share what you mean by “additional contacts” (for example, contacts who should receive the email but not appear in To/CC, or contacts who should only have the email logged), I can suggest the appropriate approach.