Security Considerations
Goldie Conversation Capture
This document describes in detail how Goldie Conversation Capture works. The goal of this document is to create full transparency on how it works so you can decide whether Goldie is aligned with your security and privacy policies.
There are several "Salesforce activity sync" products on the market. Their objective is to sync emails and calendar events from Office 365 or Google Workspace to Salesforce. The value of doing so is to have a complete activity history in Salesforce - on related account, contact, opportunity and lead records. However, Goldie Conversation Capture also captures Zoom meeting summaries, and combines these with the activity history.
No 3rd Party Exposure, No OAuth or IMAP Required
Unlike any other solution on the market, Goldie Conversation Capture does not request OAuth or IMAP access to your email/calendar host (Office365 and Google Workspace). Therefore it avoids the security/privacy risks that come with exposing all your emails and event records to a 3rd party. Neither Goldie nor any other 3rd party will get access to your email/calendar data.
Also, at no point are your emails/meetings exposed to an LLM provider (such as OpenAI). All the processing and filtering happens natively in Salesforce.
Note: if you activate Goldie's Activity Q&A or Auto-Contact Creation, your CRM data will be partially exposed to OpenAI (see below).
Email Forwarding + Salesforce Email Service
Instead of OAuth, Goldie uses a compliance feature that both Office365 and Google Workspace provide, which can Bcc all non-internal-only emails to a Salesforce email service. The email service (part of the Goldie managed package in Salesforce) filters and scans each email in-memory (without storing them) and logs only customer related email.
What about calendar events? Every customer related calendar event is scheduled through an inbound or outbound calendar invitation. This invitation (as well as any RSVP responses) are sent via email, which are in turn forwarded and processed by Goldie's email service. By monitoring your emails, Goldie can also log calendar events in Salesforce together with the RSVP status of each invitee.
You might have noticed, how Goldie uses the same paradigm as the old BCC-Salesforce feature, but with much more sophisticated capabilities and without the need for any user effort.
This paradigm entails:
Your external emails/events are only shared with Salesforce rather than any 3rd party vendor (such as Goldie) - furthermore internal-only emails are not shared at all (not even with Salesforce).
The customer related emails/events of all your users are captured, even if none of the sender/recipients have a Salesforce license. This leads to a complete conversation history and a true customer 360° view at no extra cost.
Limiting Conversation Capture to a Subset of Your Employees
While capturing customer related emails/events of all employees (rather than the ones that have a Salesforce license) is generally very desirable, there are cases where you would like to limit Goldie conversation capture to a subset of your users. You can do so by configuring the forwarding rule accordingly:
In Google Workspace configure the Content Compliance forwarding rule to only apply to particular "organizational units". Only users that belong to that organizational unit will have their emails forwarded to Salesforce and subsequently logged.
In MS Exchange configure the membership of particular "groups" as an extra rule condition in the forwarding rule. Only users that belong to the included groups will have their emails forwarded to Salesforce and subsequently logged.
What the Email Service does
Setting up the email service in Salesforce is part of the setup process and requires you to select a Salesforce user as the "running user". This means the code that filters and scans emails, runs with the permissions that the running user has in Salesforce.
It is mandatory that the selected running user has Modify-All-Data permissions in Salesforce. If you select a user without these privileges, the email service will not process any emails. For the same reason it is critical that the running user is not deactivated (e.g. if the sys-admin leaves the company). This is why Goldie includes and Apex trigger on the user object, that prevents that the running user is deactivated. An error message is displayed so that you remember to replace the running user of the Goldie email service first (see the article Deactivating a Salesforce Sys-Admin).
Once configured, the email service processes all emails that are forwarded to it. This is a two-fold process:
- Filtering
First emails are filtered as follows:
Emails that don't appear to be "hand written" are ignored (e.g. marketing emails, notification emails, out-of-office replies, etc.)
Emails that were sent to more than 20 recipients (presumably mass-emails) are ignored.
The sender OR at least one recipient of an email must have an internal email address. Otherwise it is ignored.
The sender OR at least one recipient must have an non-internal email address (in case the email forwarding was misconfigured). Otherwise it is ignored.
Emails that don't relate to an account or a lead are ignored, unless it is a Zoom summary email.
Zoom summary emails are matched to the related calendar event based on name and timeframe.
The filtering happens in-memory, so that non-customer related emails are never exposed to any Salesforce user, regardless of their privileges.
- Logging
Emails that have passed the filtering process, are temporarily stored in a custom object called Queued_Email__c. The Goldie installation process ensures that only Salesforce profiles with the Modify-All-Data permission have access to this object.
A scheduled batch Apex job that runs every 5 minutes processes all new Queued_Email__c records as follows:
Emails (which includes calendar invites and RSVPs) are matched with one or more Accounts/Opportunities/Contacts/Leads/Users, based on the sender's/recipients' email domain.
If you have the option "Display Emails in Activity History" enabled, one or more EmailMessage records are created as needed. Also, for each related Opportunity/Contact/Lead/User an EmailMessageRelation record is created. That way the email is surfaced in the activity history of the related Account/Contact/Opportunity/Lead record.
If you have the option "Display Events in Activity History" enabled, one or more Event records are created as needed. Also, for each related Opportunity/Contact/Lead/User an EmailMessageRelation record is created. That way the email is surfaced in the activity history of the related Account/Contact/Opportunity/Lead record.
In any case a Act__c record is created and for each related Account/Opportunity/Contact/Lead/User an Act_Relation__c record is created. These two custom object are part of the managed package. They store emails and events in a distilled and AI-ready format. This is an important part of Goldie Grounding Signals.
The temporary Queued_Email__c records are deleted after 30 days.
Record-Level Permissions
You might have Salesforce sharing rules configured for account/contact/opportunity/lead records. The visibility to the EmailMessage and Event records that Goldie creates are automatically controlled by the sharing rules for their "parent" account/contact/opportunity/lead record, so that no emails/events are shared with Salesforce users that don't also have access to the actual account/lead.
For the same reason, the Act__c object has a master detail relationship to the Account object. Only users that have access to the matched primary Account record have access to the emails and events, represented as Act__c records. If a user doesn't have access to a particular account record as of your sharing rules, assigned Act__c records also won't be accessible to that user.
The Goldie setting "Sync Activities to Orphan Leads" only matters if you have the option "Display Emails/Events in Activity History" enabled. If disabled, Goldie only matches emails/events to Leads, if at least one matching Account record was found. Otherwise the email/event isn't logged because Goldie isn't able to establish a master-detail relationship between the Act__c record and an account record.
How Accounts/Contacts/Opportunities/Leads are Matched
Goldie matches an email to Salesforce records by finding accounts that have the same "inferred domain" as the email domain(s) of the sender/recipients. Goldie infers the domain of an account by looking at the field Account.Website and the email domains of the account's contacts.
If there are open opportunities under a matched account, the email is also matched with that opportunity.
Leads are only matched by an exact match of the email address.
Free-mail domains (Gmail.com, Outlook.com, etc.) are always ignored. Remember that when you test Goldie Conversation Capture.
What is an Internal Email Domain?
In order for the above filter mechanism and the inbound/outbound detection to work properly, Goldie needs to understand what your company's email domain is. This is why upon installation Goldie scans the email addresses of all your active Salesforce users and infers up to three email domains that your users use - therefore "your company's email domains" - a.k.a. "internal email domains". You can inspect and update the inferred domains in Goldie's custom settings in the three fields "Company Email Domain". Should your company's email domain ever change, you must also adjust Goldie's custom settings accordingly.
Critical Security/Privacy Considerations
Domain-based matching might entail a scenario where an email is inadvertently exposed to all or a some Salesforce users. As a caveat, there are scenarios you should be aware of.
A Personal Email is Exposed to Random Salesforce Users
Imagine the following scenario:
You send a private email to your dentist using your company email address. The dentist's email address is office@pacific-dental.com.
For any reason, the dentist downloaded a white paper on your website which created a lead. In this case the email won't be stored in Salesforce, as there is no account with an inferred domain "pacific-dental.com". That's good.
For any reason, the lead was converted - therefore an account and a contact was created for the dentist in Salesforce. The inferred domain of the account is "pacific-dental.com". This means that Goldie would consider any email to somebody with the domain "pacific-dental.com" customer related and log your private email the/from the dentist in the account's activity history. Now any Salesforce user that has access to this account record can see your emails. That's most likely not desirable.
Remedy
Remind your users to not send personal emails from their corporate account.
Consider limiting the users for which the forwarding rule in MS Exchange or GWS to a subset of your employees (see above).
A Confidential Email is Exposed to Random Salesforce Users
Imagine the following scenario:
The CFO of your company sends a confidential email to a law firm working for your company. The recipient's email address is saul@goodmanlaw.com.
For any reason, somebody at the law firm downloaded a white paper on your website which created a lead with the email address liddy@goodmanlaw.com. In this case the email won't be stored in Salesforce, as there is no account with an inferred domain "pacific-dental.com". That's good.
For any reason, the lead was converted - therefore an account and a contact was created for the saul@goodmanlaw.com in Salesforce. The inferred domain of the account is "goodmanlaw.com". This means that Goldie would consider any emails to somebody with the domain "goodmanlaw.com" as customer related and log the confidential email in the account's activity history. Now any Salesforce user that has access to this account record can see the confidential email. That's most likely not desirable.
Remedy
Avoid that accounts in Salesforce exist that relate to business partners that send/receive confidential emails.
Consider limiting the users for which the forwarding rule in MS Exchange or GWS to a subset of your employees (see above).
OpenAI Utilization
While most Goldie features are 100% Salesforce native, there are two features that partially expose your CRM data to a 3rd party. Goldie uses OpenAI's Chat API in order to provide you with these two features which can be activated separately:
Activity Q&A
This feature let's you "converse" with an account's activity history and answer question about the content of previous emails and meeting summaries. To that end Goldie compiles an activity log comprised of all emails and meeting summaries and sends this activity log to OpenAI as part of a prompt.
Auto-Contact Creation
This feature creates or augments contact records in Salesforce based on email signatures Goldie's Conversation Capture found in inbound emails. Goldie sends the raw email signature (but not the email message itself) to OpenAI and asks the LLM to extract first name, last name, title, phone numbers etc. in a structured format.
OpenAI and Privacy Considerations
OpenAI's Enterprise Privacy's document (section "API Platform FAQ") speaks to the privacy related topics such as
SOC2 compliance: Yes, they are SOC2 compliant.
HIPAA compliance: They are able to sign Business Associate Agreements.
Data retention: Normally 30 days but you can also request zero data retention (ZDR) for eligible endpoints if you have a qualifying use-case.
Sources of training their models: Data from the API Platform isn't used for training OpenAI's models.