Merge pull request #308147 from v-rakegurram-MSFT/patch-28

(AzureCXP) fixes MicrosoftDocs/azure-docs-pr#506997

Author: prmerger-automator[bot]

articles/azure-functions/functions-bindings-azure-sql-trigger.md

@@ -43,6 +43,9 @@ Changes are processed in the order that their changes were made, with the oldest
 2. Changes are "batched" together for a row. If multiple changes are made to a row between each iteration of the loop then only a single change entry exists for that row which will show the difference between the last processed state and the current state
 3. If changes are made to a set of rows, and then another set of changes are made to half of those same rows, then the half of the rows that weren't changed a second time are processed first. This processing logic is due to the above note with the changes being batched - the trigger will only see the "last" change made and use that for the order it processes them in
 
+> [!NOTE]
+> Azure SQL change tracking can detect row-level changes in tables that use encryption technologies such as Always Encrypted or Transparent Data Encryption (TDE). However, the Azure SQL trigger doesn’t decrypt or expose encrypted column values in the change payload. The trigger can detect that a change occurred but can’t access the decrypted data for those columns.
+
 For more information on change tracking and how it's used by applications such as Azure SQL triggers, see [work with change tracking](/sql/relational-databases/track-changes/work-with-change-tracking-sql-server) .
 
 [!INCLUDE [functions-sql-database-authentication-note](../../includes/functions-sql-database-authentication-note.md)]