What Changed
The BitSight Function App connector definition (BitSight_API_FunctionApp.json) received a UI page update to reflect the connector migration to the Logs Ingestion API introduced in v3.1.0.
- Connector description updated: now explicitly states ingestion uses the Logs Ingestion API (DCR) rather than the legacy direct workspace injection
- Step 6 deployment instructions revised: the previous instructions prompted operators to copy the Workspace ID and Primary Key (via copyable UI controls) before deployment – those controls have been removed; the updated instructions require the BitSight API Token plus Azure credentials (Client ID, Client Secret, Tenant ID, Object ID)
- ARM deployment step 4 updated: added explicit checkbox acknowledgement and renamed the final action from “Review + create” to “Review + Create” then “Create”
- Workspace shared keys permission block reformatted from an inline permissions entry to the customs section alongside the Azure Functions permission entry – no change to the permission requirement itself
No changes to polling logic, KQL transforms, DCR configuration, or ingestion schema. This is a UI fidelity fix ensuring the connector setup page reflects the actual authentication model used by the deployed Function App.
Affected Files
Solutions/BitSight/Data Connectors/BitSightDataConnector/BitSight_API_FunctionApp.json
(packaging artefacts: 3.2.0.zip, ReleaseNotes.md, mainTemplate.json)