Problem
During a Profile API workflow run (e.g., getCustomerAndLoyaltyByReservationCompositeKey), users may encounter the following error when promoting changes to production or running an index:
Build index: ID Field "reservation_composite_key" contains values that are not URL-safe. Please select a different ID Field.
This issue can occur even when the primary key appears to contain only standard alphanumeric and underscore characters during initial checks.
Root Cause
The error occurs when one or more values in the field used as the index ID (e.g., reservation_composite_key) include characters that are not URL-safe.
In this case:
The key was built using a concatenation pattern similar to:
CONCAT(confirmationCode, '_', createDate, '_', hotelCode)
Some source data values (e.g., from a reservation or transaction event table) contained special characters such as forward slashes ( / ), which are not URL-safe.
These characters caused the index build to fail during the workflow execution.
Solution
Step 1. Identify Non-URL-Safe Characters
Run a query to detect records containing non-URL-safe characters in the key field.
For example:
SELECT pk
FROM Unified_Coalesced
WHERE datasource = '<your_datasource>'
AND pk LIKE '%/%'
This helps locate any values that may need cleaning or encoding.
Step 2. Apply url_encode() During Key Construction
To prevent this issue, apply the url_encode() function when constructing the key field.
Example:
url_encode(CONCAT(confirmationCode, '_', createDate, '_', hotelCode)) AS reservation_composite_key
This ensures that all parts of the key — including any special characters — are properly encoded and safe for use in the Profile API index.
Step 3. Validate and Rebuild the Index
After updating the query:
- Validate the results in a sandbox or test environment.
- Promote the updated configuration to production.
- Rerun the index build or affected workflow to confirm successful completion.
Example Scenario
A workflow build failed with the “not URL-safe” error even though the key appeared valid in most cases. Further investigation found that a few records contained forward slashes (/) in the confirmationCode portion of the key.
After applying the url_encode() function to the concatenated key, the index built successfully without modifying the overall structure or logic of the query.
Best Practice
Always use url_encode() when defining a primary or index key that is constructed from multiple source fields.
Periodically validate key fields for hidden or special characters that may cause encoding issues.
Test workflow index builds in a sandbox environment before promoting to production.