Egnyte for Salesforce – Frequently Asked Questions

This article answers common questions about how the Egnyte for Salesforce integration works. For setup and configuration, see:

• Egnyte for Salesforce - Overview
• Egnyte for Salesforce Installation Steps
• Egnyte for Salesforce Administration
• Customizing Salesforce Integration with Custom Paths
• Salesforce Flows with Egnyte Actions

 

Skip Ahead To...

Folder Structure and Custom Paths

Folder Creation Behavior

Notes, Files & Attachments

Permissions

Lightning Experience

Upgrades and Compatibility

 

Folder Structure and Custom Paths

How does the integration decide where a record's folder is created in Egnyte?

When the Default Folder Path option is checked (the default), record folders are created under /Shared/Salesforce.com/<Object Name>/<2-letter hash>/<Record Name>. The two-letter hash is the first two characters of the record name (after spaces and periods are stripped), converted to uppercase (for example, J. Smith Co becomes JS). The hash exists for performance: Egnyte has a limit of 50,000 subfolders per folder, and the hash spreads records across subfolders so that large organizations do not reach it. If a Custom Folder Path is selected instead, the integration follows that path exactly, and no hash folder is added.

If an object has a Parent Object set in its Egnyte Sync Configuration, its folder is created inside the parent record’s folder instead. Parenting is supported up to three levels deep (for example, /Shared/Salesforce.com/Accounts/AC/Acme/Contacts/Jane Doe/Custom Object/...), and one object can be the parent of several child objects.

If the parent lookup on a record is empty (for example, a Contact with no Account), the folder is created at the object’s own path instead: the Custom Folder Path if one is configured, otherwise the default path. When a record does have a parent, the parent’s folder takes precedence, and any Custom Folder Path on the child object is ignored.

Can the integration use an existing folder structure in Egnyte instead of creating folders under /Shared/Salesforce.com?

Yes. Use Custom Folder Path and Custom Folder Name on the object's Egnyte Sync Configuration. Create a formula field on the Salesforce object that resolves to the desired path (everything after /Shared/), then select that field as the Custom Folder Path. See Customizing Salesforce Integration with Custom Paths for the walkthrough.

Is it possible to rename or move the Salesforce.com root folder?

Not directly. The /Shared/Salesforce.com root is fixed for default paths. To place record folders anywhere else, use Custom Folder Paths.

Can records of the same object go to different locations based on a field value (for example, active vs. inactive clients)?

Yes. Build a formula field that returns a different path depending on the field value, for example IF(Active__c = "No", "Clients/Ex-Clients", "Clients/Active") and select it as the Custom Folder Path. When the field changes, the integration moves the folder to the new location.

What happens to the Egnyte folder when a record's name (or a field used in its path) changes?

The integration renames or moves the existing folder to match. A new folder is created only when more than one record was mapped to the same folder (multimapping). In that case the renamed record gets its own new folder and the original folder stays with the remaining records.

How can the new folder be created for existing records after it is added to the folder template?

Adding a path to an object's Egnyte Folder Template only applies to records created afterwards. To create it for existing records, run the Create Template Folders bulk action for that object from Egnyte Domain Configuration → Bulk Actions. Folders are created asynchronously through the sync queue, so they may take time to appear. Monitor progress in the Egnyte Sync Queue tab.

Why did existing folders not move after the Sync Configuration (parent object, custom path) was changed?

Sync Configuration changes only affect records created or updated after the change. To restructure existing folders, run the Update Folder Locations bulk action for the object.

A "blank" record update (saving without changing any field used in the path, folder name, or metadata) does not trigger a folder update. The trigger only creates a sync queue item when one of those fields actually changes.

Back to Top...

 

Folder Creation Behavior

Is it possible to create folders for only some records (for example, only active accounts or only open matters)?

The Create Root Folder setting on a Sync Configuration is all-or-nothing: when checked, a folder is created for every record of that object. The integration has no built-in record filter. Three options are available:

1. Uncheck Create Root Folder: Folders are then created only when a user first opens a record page that contains the Egnyte component.
2. Use a custom path to segregate records: Route unneeded records to a separate, restricted folder via a formula-based Custom Folder Path.
3. Use Salesforce Flow (package 3.8+ or above): Enable Flow Only on the Sync Configuration and build a record-triggered flow with a Decision element (or entry criteria) so only qualifying records reach the Mapped Folder Creation action. See Salesforce Flows with Egnyte Actions. All Sync Configuration settings (paths, names, templates) still apply to folders created this way.

Does the Mapped Folder Creation flow action return the Egnyte folder ID?

No. Mapped Folder Creation runs in the trigger context and does not call Egnyte directly. It only creates a sync queue item that is processed later in a separate transaction, so no folder ID exists at that point.

If the folder ID is needed on the record, call the Unmapped Folder Move/Rename action with the same origin and target path. This does not move the folder but returns its folderId. Because it makes a callout, it must run in an asynchronous (scheduled) path of a record-triggered flow or in a non-triggered flow. 

What happens in Egnyte when a Salesforce record is deleted?

The folder and its contents remain in Egnyte. The integration never deletes folders or files. If the content is no longer needed, delete the folder in Egnyte manually, or via a flow using the Unmapped Folder/File Delete action. Note that the Mapped Folder Deletion flow action removes only the mapping between a record and its folder, it does not delete the folder itself.

Record-to-folder mapping behavior

From package 3.11 onwards, deleting a record also removes the record-to-folder mapping. If a record is later re-created with the same name and path, it reuses the existing folder.

In the following cases, the mapping is left in place when a record is deleted:

• Packages before 3.11
• Flow Only setups with no delete flow calling Mapped Folder Deletion
• Custom objects whose Egnyte triggers were generated before 3.11 (those triggers have no after-delete handler and are not regenerated on upgrade)

When the old mapping remains and a record is re-created, the behavior differs by path type:

• Default path: the re-created record collides with the old mapping and a new folder is created with ~1 appended to the name. The original folder is not reused.
• Custom path: no new folder is created, but both the deleted record and the new one are mapped to the same folder. Renaming or re-pathing the new record creates a new folder rather than moving the existing one. To clear stale mappings at scale, contact Egnyte Support with the original record IDs.

The integration created thousands of empty folders. Can it clean them up?

No. The integration does not remove empty or orphaned folders. Cleanup is done manually in Egnyte or through an Egnyte Professional Services engagement.

What should be checked when the sync queue has a backlog and folders are not being created?

Open Egnyte Domain Configuration and click Start Processing Sync Queue. This restarts the scheduled job if it has stopped. Check queue status in the Egnyte Sync Queue tab. If the queue does not drain after restarting, contact Egnyte Support.

Back to Top...

 

Notes, Files & Attachments

How to stop the "Notes, Files & Attachments" folder from being created in every record folder?

Uncheck Upload Files & Attachments (and Upload Notes, if enabled) on the object's Egnyte Sync Configuration. In package 3.6 and later these settings are per object, not domain-wide.

The Create Root Folder and Is Default Folder Name settings are unrelated and do not control this folder.

If Upload Files & Attachments is disabled, will it affect files in Salesforce?

No. Disabling the setting only stops the integration from copying new Salesforce Files, Attachments, and Notes to Egnyte. The integration does not create or modify Salesforce Content Documents, so other Salesforce processes that depend on them (for example, document generation tools) are unaffected.

When Upload Files & Attachments is enabled, do the uploaded files appear in Salesforce's Files related list?

No. Files and attachments are copied to the Notes, Files & Attachments subfolder inside the record's Egnyte folder. Nothing changes on the Salesforce Files related list unless Delete Files & Attachments is also enabled, in which case the Salesforce copy is removed after a successful upload. Uploads are limited to 12 MB per file due to Salesforce callout limits.

Back to Top...

 

Permissions

Users have no permissions on folders the integration creates. Why, and how to fix it?

The integration assigns Egnyte folder permissions only when a user opens a record page that contains the Egnyte component (canvas app, Lightning component, or Visualforce page). At that moment the visiting user is granted the level set in Default Permission on the Egnyte Domain Configuration, or the level set on the component itself.

Folders created any other way (by trigger on record creation, bulk actions, or flows) receive no explicit permissions. They inherit from their parent folder in Egnyte, the same as any other Egnyte folder.

To grant permissions to groups or specific users automatically at folder-creation time, use the Assign Folder Permissions action in a Salesforce Flow (package 3.8+), or set permissions on the parent folder in Egnyte so new record folders inherit them.

Why do users still receive Owner permission after the Default Permission was changed from Owner to Viewer?

Two settings determine the permission granted on visit:

1. Default Permission on the Egnyte Domain Configuration tab.
2. The permission parameter on the Egnyte component itself, set when the component was added to the Lightning record page (App Builder) or in the Visualforce markup (permission="Owner"). This overrides the domain default.

Check the component configuration on each record page. If it has an explicit permission set, that value takes precedence.

Does lowering Default Permission reduce permissions users already have?

No. The integration only adds a permission entry when the visiting user has no permission or a lower level than the configured default. It never downgrades or removes existing permissions. To reduce permissions, change them in Egnyte directly or use the Assign Folder Permissions flow action.

The Salesforce record owner doesn't automatically appear in the Egnyte folder's permissions. Is that expected?

Yes. Permissions are granted to users who visit the record with the Egnyte component present, not based on record ownership. If the owner has not visited the record, they will not have an explicit entry. Use a flow with the Assign Folder Permissions action if owner-based permissions are required.

Back to Top...

 

Lightning Experience

Is there a Lightning component that allows dynamic page layouts to be used instead of the Visualforce page?

Yes. The package includes EgnyteComponent, an Aura component compatible with Lightning App Builder and dynamic page layouts. Look for it under Custom – Managed in the App Builder component list. The Visualforce approach in the Administration article remains supported for orgs that prefer it.

My Sync Configuration doesn't show Folder Templates in Lightning.

In Lightning, related lists (including Egnyte Folder Templates) appear under the Related tab at the top of the Sync Configuration record, rather than inline as in Classic.

Back to Top...

 

Upgrades and Compatibility

What should be expected when upgrading the package? Is there downtime? Will the configuration be wiped?

Under normal circumstances there is no downtime, no user-visible interruption, and no configuration change. Upgrades are backward compatible; the Domain Configuration, Sync Configurations, folder templates, and custom paths are retained.

After upgrading:

• Review new settings introduced since the previous version. There may be many if upgrading from an older release.
• The Egnyte Sync Configurations page layout is not updated automatically. Add new fields to the layout manually (see Add Egnyte Sync Configurations Layout in the Administration article).
• If the Egnyte permission sets are used, users receive access to new fields automatically. If custom profiles were built instead, read access to new package fields (for example, efs__EgnyteFolderPath__c) may need to be granted manually. Egnyte recommends the provided permission sets for this reason.

Because every Salesforce org has different customizations, always test the upgrade first in a sandbox connected to a trial Egnyte domain before upgrading production.

Is there a rollback or downgrade option if something goes wrong after upgrading?

No. Salesforce does not support downgrading managed packages. This is why Egnyte strongly recommends validating the upgrade in a sandbox first.

Is the package compatible with Salesforce's ICU locale format update (API version 45.0 or higher)?

Yes. Package 3.7.7 updated all Apex classes to API version 45, and package 3.8 updated all remaining components. Upgrade to the latest version to be fully compliant.

If custom Sync Configurations were created on older versions, the integration generated Apex triggers and test classes in the org. These are not part of the managed package and are not updated automatically. To update them:

1. In a sandbox, go to Setup → Apex Triggers (and Apex Classes), open each Egnyte-generated trigger and test class, click Edit → Version Settings, and set the Salesforce.com API version to 45.0 or higher.
2. Save, run tests, and deploy to production using a change set.

There is no need to delete or recreate the triggers. Alternatively, package 3.8 introduced Flow Only mode, which removes the need for generated Apex triggers entirely.

Is it possible to use an Egnyte Service Account for the integration connection instead of a regular user?

Yes, and this is the recommended setup. The existing integration user can be converted to a Service Account, and the connection continues to work. If the integration needs to be re-authenticated (for example, after a password change), the account must be temporarily converted back to a regular user, because Service Accounts cannot log in interactively.

Is it possible to map a new custom object, or re-point an existing custom path to a different object?

Yes. A new Egnyte Sync Configuration can be created for the object, with its parent, templates, and custom path configured as described in the Administration article. If the original implementation was done by Egnyte Professional Services with custom formulas or Apex, changes to that customization are handled through a Professional Services engagement arranged via the Egnyte Account Manager.

Back to Top...