Use case- The customer has extended the recipient table to add two custom columns. The first column has a unique identifier to identify a recipient record—the second column stores the same identifier in an encrypted format. The customer has created a custom workflow to encrypt all the values of the first column and store them in the corresponding second column.
The customer now wants to use this encrypted record to identify a recipient in a web app. So, for example, the web-app URL should look like this: https://clientsurl/unsubscribe/value/TVGr4UfKr9%2BuNlQulVDy2w%3D%3D
TVGr4UfKr9%2BuNlQulVDy2w%3D%3D is the encrypted value. However, as soon as this URL is passed in a browser, the browser, considering %2B and %3D as special characters, encodes it to https://clientsurl/unsubscribe/value/TVGr4UfKr9+uNlQulVDy2w==
The browser might be converting the special characters under the URL encoding scheme since the customer was not passing the encrypted identifier (extended column) as a query parameter in the URL. The customer should use a separator here and pass the encrypted identifier as a query parameter and the browser won’t decode it.
For example: https://clientsurl/webApp/unsub?encrypted identifier column name=TVGr4UfKr9%2BuNlQulVDy2w%3D%3D instead of https://clientsurl/unsubscribe/value/TVGr4UfKr9%2BuNlQulVDy2w%3D%3D
In order for the un-subscription to work, the customer will also have to modify the un-subscription web app so that it takes this parameter into consideration for unsubscribing the recipient.