Secure webhook credentials in automations
Webhook request settings — including the URL, authorisation headers and body templates — may contain credentials. Hub now saves these through an administrator callable into server-only storage so they are never visible in the browser or copied into Activity logs. ## How webhook credential protection works When you save or update an automation that contains a **Send webhook** action, Hub: 1. Extracts the full request configuration (URL, headers, body template). 2. Stores it in a server-only collection (`automationWebhookConfigs`) that is inaccessible to browser clients. 3. Replaces the credentials in the public automation document with a scoped reference ID and a safe destination label (the hostname only). When the automation fires, the server resolves the reference and uses the full configuration without copying credentials into Activity or execution history. Activity events record the action *type* and outcome, not the request settings. **What workspace members see:** The automation editor shows a saved secure request notice with the destination hostname. Existing headers are preserved when you edit the URL or body — you do not need to re-enter credentials after making other changes. ## What is protected - Webhook URLs (including path and query parameters that may contain tokens) - Request headers (including Authorization and API key headers) - Body templates ## What is not changed - Automation triggers, names, enabled state and non-webhook actions are unaffected. - The automation continues to fire normally — no outbound requests change. - Existing cloud logs from before this protection was introduced are not modified. ## Migrate older saved requests Automations saved before this protection was introduced may still contain credentials in their public documents and historical activity records. Hub provides an explicit migration tool for workspace owners and admins. ### Preview and apply 1. Open **Settings → Automations**. 2. Select **‹ ›** (overflow actions) → **Secure saved webhook requests**. 3. Select **Review saved requests** to scan the workspace without making changes. Hub reports: - How many automation definitions need updating. - How many execution snapshots contain request settings. - How many Activity events include action configurations. 4. If records are found, select **Secure existing requests** to apply the changes. Applying moves credentials to protected storage, removes copied request settings from execution history and Activity, and preserves all outcomes. It does not send webhooks, delete events or change external credentials. A stopped or incomplete preview never enables applying changes. You can run the tool again to continue where you left off. ## Browse complete Activity history The Activity history page (**Activity** in the workspace) now uses server-side pagination and structured filters, so you can browse the full history without a fixed record limit. **Filters available:** - Activity kind - Actor role (admin, automation, customer, etc.) - Specific team member - Automation rule - Date range - Conversation-only view **Controls:** - **Load older activity** — fetches the next page of results. - **Refresh** — reloads from the latest events. - **Retry** — resumes from the last loaded position after a failure. The status line below the filters shows how many matches are in the currently loaded set and whether older history is available. Text search, sorting and view counts apply to the events already loaded. ### Automation recent fires The **Recent fires** section on each automation editor page also uses server-side pagination. Select **Load older outcomes** to browse beyond the most recent results, and **Refresh** to check for new activity. A stopped or incomplete pass keeps the loaded results in place. ## Firestore rules update This release also removes an overlapping member-write rule that previously allowed workspace members to write to automations directly. Automation configuration now requires owner or admin access and goes through the `saveAutomation` callable. The public automation document is updated only for non-secret fields (name, enabled state, trigger); credential changes always go through the server path.