Skip to content

Two-way sync on Azure

Two-way sync reflects changes made directly in your container back into Salesforce. Read Two-way sync first for what it does and does not cover. This page is the Azure side.

Two-way sync is a premium feature. It is switched on for your org by Sliick. Contact Sliick before you start.

Requires a StorageV2 or BlobStorage account kind, and the default EventGridEvent delivery schema. Do not use the CloudEvents schema.

The order matters, because step 3 needs a URL that only exists after this.

  1. Open Sliick Files Setup → Sync.
  2. Enter your storage account’s resource id, in the form /subscriptions/SUB_ID/resourceGroups/YOUR_RG/providers/Microsoft.Storage/storageAccounts/YOURACCOUNT. Casing does not matter.
  3. Turn on Enable two-way sync and save.

The page then shows your org’s private webhook endpoint URL with a copy button.

Treat that URL like a credential. It contains a secret unique to your org. Do not share it.

2. Register the Event Grid provider, if you never have

Section titled “2. Register the Event Grid provider, if you never have”

If this Azure subscription has never used Event Grid, register it first. Skipping this makes creation fail with “Microsoft.EventGrid is not registered in Azure Subscription …“.

az provider register --namespace Microsoft.EventGrid
# poll until it prints Registered, about 1 to 2 minutes:
az provider show --namespace Microsoft.EventGrid --query registrationState -o tsv

3. Create the system topic explicitly, then the subscription

Section titled “3. Create the system topic explicitly, then the subscription”

Create the system topic explicitly. Do not use the storage-scoped az eventgrid event-subscription create shortcut. When the Event Grid provider registration is fresh, its implicit system-topic creation can silently fail, leaving a subscription that reports Succeeded but never receives a single event.

az eventgrid system-topic create \
  --resource-group YOUR_RG \
  --name YOURACCOUNT-events \
  --location <storage account region> \
  --topic-type Microsoft.Storage.StorageAccounts \
  --source "/subscriptions/SUB_ID/resourceGroups/YOUR_RG/providers/Microsoft.Storage/storageAccounts/YOURACCOUNT"

az eventgrid system-topic event-subscription create \
  --resource-group YOUR_RG \
  --system-topic-name YOURACCOUNT-events \
  --name Sliick-blob-events \
  --endpoint-type webhook \
  --endpoint "<the URL copied from Sliick Files Setup>" \
  --included-event-types Microsoft.Storage.BlobCreated Microsoft.Storage.BlobDeleted \
  --subject-begins-with "/blobServices/default/containers/YOUR_CONTAINER/blobs/<your root prefix>/"

<your root prefix> is Salesforce-Files-<your org id> unless you set a custom storage root folder.

Subscription creation validates against the Sliick endpoint automatically, and the handshake is answered for you. It only succeeds with the copied URL: deliveries without your org’s token are rejected.

A blob landing under a record’s folder shows on that record in a few seconds, three to fifteen seconds in live testing.

Microsoft.Storage.BlobDeleted only fires for a true permanent delete. With soft delete for blobs enabled, which is what makes Sliick’s own deletes restorable, a normal delete call soft-deletes instead, so that event never fires.

So while soft delete is on, a blob removed directly in the container is not parked in Deleted Files and does not disappear from its record. The Salesforce side stays as it was until someone removes the file there too.

This is an Azure event-delivery limitation, not a reason to turn soft delete off. Adds, edits and renames sync normally regardless.