Known Issues & Fixes¶
If you run into something unexpected, check the list below. If your issue isn't covered, feel free to open a GitHub issue or reach out directly at ansukh@astertrail.com.
"View All" Attachments page opens and immediately closes
When does it happen?
In some sandbox environments, clicking "View All" on the Google Client: Attachments component causes the page to open briefly and close itself automatically.
Root Cause
This happens when Platform Cache is unavailable. During installation, the package creates a Platform Cache Partition named GoogleCloudClient. If your sandbox has 0 cache storage provisioned, screens that rely on Platform Cache may fail to load.
Fix
- Go to Setup
- Search for Platform Cache
- Click into the partition named GoogleCloudClient
- Click Edit
- Under Provider Free, set: Session Cache =
1and Org Cache =1 - Save
This allocates minimal cache and resolves the issue.
Duplicated Google Drive folders are created for the same record
When does it happen?
With a Folder Structure configured, a record can end up with more than one Drive folder (most visibly when several users upload to the same record at the same moment).
Root Cause
Google Drive's search index is eventually consistent: a folder that was created moments ago is not always returned by a search yet, especially on a Drive holding a large number of items. When each file resolved its own folder, the search for the next file found nothing and created a second folder.
Google Client now resolves the folder once per upload, starting as soon as the files are selected so it resolves while the content is still transferring, and remembers the result in the Platform Cache partition named GoogleCloudClient. Every file in that upload reuses the same folder, so Google Client never has to ask Drive for a folder it just created.
Fix — allocate Org Cache
- Go to Setup
- Search for Platform Cache
- Click into the partition named GoogleCloudClient
- Click Edit
- Under Provider Free, set: Session Cache =
1and Org Cache =1 - Save
Uploads and folder placement keep working correctly whether or not cache is allocated — allocating Org Cache is what guarantees a single folder per record.
"Google Client Config" record shows a deprecation warning after upgrading to v1.3.0
When does it happen?
After upgrading to v1.3.0, opening the GoogleClientConfig__mdt record in Setup (Custom Metadata Types → Google Client Config → Manage Records) may display the following banner:
This Google Client Config has been marked deprecated. You might lose any changes you make to the component if you later upgrade to a package version that restores it.
Why does this happen?
In previous versions, the package shipped a pre-built GoogleClient metadata record. On every upgrade, Salesforce re-deployed it as a full overwrite — silently wiping any values you had manually configured (certificate name, service account email, API keys, etc.).
To prevent this data loss, the record was removed from the package in v1.3.0. Salesforce marks it as deprecated because it no longer belongs to any package version — which is exactly the intent.
Is anything broken?
No. Your configuration data is intact, the app continues to work exactly as before, and no action is required. The warning is purely informational.
"Data Not Available" error during authentication or setup
When does it happen?
You may see this message in Salesforce:
Data Not Available: The data you were trying to access could not be found.
In this context, it usually means the Salesforce Identity Provider is not enabled for the org.
Fix
- Go to Setup.
- Search for Identity Provider in Quick Find.
- Open Identity Provider.
- Click Enable Identity Provider.
- Click Save.
- Return to Google Client setup and try the action again.
Files stay on the Lead after it is converted
When does it happen?
A Lead that has Google Client files is converted. The files stay on the Lead and do not appear on the new Account, Contact, or Opportunity.
Root Cause
Salesforce carries its own files over during conversion. It knows nothing about Google Client files, so nothing is moved for you.
Fix — move them with a flow
Each file-to-record association is stored as a Google File Link record, and that record is editable. A record-triggered flow on Lead that runs when the Lead is converted can point those links at the new record.
What to get right:
- Find the right links. Look for Google File Link records where Linked Object Id equals the converted Lead's Id.
- Decide move or copy. Changing Linked Object Id moves the file to the new record. Creating a second link keeps it on the Lead as well — copy Google File across and set Is Additional Link? to true.
- Keep the rest of the link in step. Linked Object Type and Linked Object Name are what users see in Linked Records. Share Type and Visibility decide who can reach the file, so carry them over from the original link instead of picking new values.
- Choose one target per file. Conversion can create an Account, a Contact, and an Opportunity. Linking the same file to all three means it shows up on all three.
The Google Drive file itself does not move. Only the Salesforce record it appears on changes.
"Certificate cannot be null" when saving and validating Google Drive configuration
When does it happen?
This can happen the first time you save and validate Google Drive configuration in the Google Client app.
Root Cause
The configuration save and validation can run too close together. The save is still being committed when validation starts, so validation may not see the certificate information yet and returns a certificate error.
Fix
- Save the Google Drive configuration.
- Wait 10-15 seconds.
- Click Validate again.
- If the same message appears, wait a little longer and click Validate again.
After the authentication details finish saving, validation should use the new certificate information correctly.
Reading a file's text in a flow right after uploading it returns nothing
When does it happen?
A flow uploads a file to Google Drive and then uses Extract File Content as Text from Google Drive on it in the same run. Instead of the text, the action reports that text is not available yet.
Root Cause
Text is read from the preview copy Google prepares for the file, not from the uploaded file itself. Google takes a few seconds to prepare it, and the flow reaches the next step long before that.
Fix
- Split the work in two. Upload in one flow, and read the text in a second flow that runs afterwards.
- For a record triggered flow, put the reading step on a scheduled path a few minutes later.
- Plain text files such as
.txt,.csvand.mdneed none of this. They are read straight from the upload and are ready immediately.
The same wait applies to previews and AI summaries, so a file that cannot be read yet usually cannot be previewed yet either.