|
4 Products Updated |
2 New Features |
| 7 Improvements | 5 Bugs Fixed |
When configuring the Scan Behind Login feature, button-type form fields — such as the login button — are now displayed as read-only in the Edit Fetch Form Details modal, matching the behavior already in place in the Scan Behind Login setup modal. Previously, the two modals showed these fields differently, which could cause confusion during setup.
Inconsistent field states between configuration screens create uncertainty. When both modals show the same read-only view, there is less risk of unintended edits and configuration audits are more straightforward.
- Button-type fields display consistently as read-only across both Scan Behind Login modals.
- Reduces risk of unintended edits during configuration.
- Clearer, more predictable setup experience for administrators.
CCM Pro and CCM Advanced now dispatch two lifecycle events — trustarc-ccm-ready and trustarc-consent-updated — as CustomEvent objects directly on the browser document.
trustarc-ccm-ready fires on every page load once CCM has initialized and determined the user's consent state. trustarc-consent-updated fires every time a user submits or changes consent preferences. Both events carry a structured payload: event name, timestamp (Unix ms), per-category consent map, and consent model (opt-in, opt-out, or none). When Push CCM Events to dataLayer is enabled, both events are also pushed to the browser's dataLayer.
Integrating consent state into analytics, tag management, and marketing platforms previously required brittle workarounds. With standardized document-level events, developers can respond to consent changes using familiar browser patterns — making integrations faster to build and easier to maintain.
- Use standard
addEventListener()patterns — no proprietary APIs to learn. - Structured payloads with per-category consent state and consent model on every event.
- Consistent event behavior across both CCM Pro and CCM Advanced.
- Compatible with existing
dataLayerintegrations — both fire at the same lifecycle points.
If you use the Push CCM Events to dataLayer setting, verify that existing window.dataLayer behavior continues as expected — both dispatch at the same lifecycle points with the same payload.
This release resolves five separate issues in the Mobile App Consent SDK:
Region Switching and Consent Re-triggering
Switching between regions with different MAC domains previously caused app crashes and prevented consent from re-triggering. The SDK now handles region transitions correctly.
Consent Manager Display on ATT Denial
When ATT was denied, calling openCM() on first launch failed to display the Consent Manager Opt Out Window. This is now corrected — openCM() reliably presents the opt-out window regardless of ATT status.
React Native Bridge Initialization
A crash occurred during React Native bridge initialization when RCTCallableJSModules was not properly set in TrustArcMobileSdk. The initialization sequence is now stable.
Back Button Banner Behavior
Tapping the back button previously displayed the wrong banner. Navigation behavior is now corrected so the appropriate banner is always shown.
Tracker Table Translation Support
The Company and Domain columns in the consent UI tracker table did not support translation. Both columns are now fully translatable.
App crashes and inconsistent consent displays are not just bad user experiences — they are compliance risks. These fixes ensure your mobile consent flow is stable, that users always see the right prompts, and that multilingual users get a fully localized experience.
- Users can switch regions without encountering crashes, and consent re-triggers correctly.
- The Consent Manager Opt Out Window displays reliably on first launch, regardless of ATT status.
- React Native integrations no longer experience crashes during bridge initialization.
- Back navigation always shows the correct banner.
- The tracker table is fully localizable, supporting a seamless multilingual consent experience.
CPM now allows administrators to configure expiry reminder emails to send a specified number of days before a consent record expires. Using a new Expiry Reminder email template type, reminders can be tailored by jurisdiction, form, and brand. Previously, notifications could only be triggered once consent had already expired.
Expired consent creates compliance gaps and requires effort to remediate. Proactive reminders give data subjects the opportunity to renew before the deadline — reducing lapsed consent and the risk of processing data without a valid basis.
- Notify data subjects before consent expires, not after.
- Configure reminder timing using predefined or custom day values.
- Apply settings by jurisdiction, form, or brand for maximum flexibility.
- Existing expiry notification behavior is unchanged when no reminder is configured.
CPM now supports copy-and-paste for the 6-digit verification code used in the Display Latest Data email verification flow. Users can paste the full code directly into the input field, and the system automatically populates and advances the verification. Previously, codes had to be entered manually, increasing the chance of input errors.
Manual code entry is a friction point that causes abandonment — especially on mobile. Reducing that friction means more data subjects complete the verification flow, keeping your consent records current and accurate.
- Paste the full 6-digit code in one action — no manual digit-by-digit entry.
- Fewer input errors during email verification.
- Faster, more seamless verification for data subjects.
- Existing verification behavior fully preserved.
CPM now uses the language selected during consent form submission when sending email communications and rendering landing pages. The system stores the submission language and applies the matching template for consent confirmations, expiry notifications, and landing page experiences. Previously, these could appear in a different language than what was used during the original submission.
Receiving a consent confirmation in the wrong language is confusing and erodes trust. Matching the communication language to the original submission language is both a better experience and a clearer demonstration of respect for the data subject's preferences.
- Email communications and landing pages match the language used during consent submission.
- More consistent and localized experience for data subjects.
- Reduces confusion from mismatched language experiences.
CPM now supports updating consent status through an external API, allowing consent records to move from Pending to Active without requiring Double Opt-In (DOI) email delivery. Organizations can suppress DOI emails using a dedicated request parameter during consent creation — useful for automated workflows where a DOI loop is handled through a separate channel or is not required at all.
Many automated consent workflows — such as in-person capture or third-party integrations — do not need a DOI email loop. The inability to suppress DOI emails previously created unnecessary steps. This enhancement removes that constraint, making CPM a better fit for complex, API-driven consent architectures.
- Update consent records from Pending to Active through the API, without DOI email delivery.
- Suppress DOI emails on a per-request basis using a dedicated parameter.
- Greater flexibility for automated and integration-driven consent workflows.
- Existing DOI behavior is unchanged when suppression is not enabled.
CPM now displays more detailed breadcrumb navigation on deeper pages such as detail views, edit screens, review pages, and nested record configurations. Previously, breadcrumb trails only reflected the primary navigation structure, making it difficult to orient within complex workflows. Breadcrumb paths now show additional navigation levels throughout the Arc interface.
Deep navigation without clear breadcrumbs forces users to rely on the browser back button and lose context. Better breadcrumbs mean faster orientation, fewer accidental exits, and more confident navigation through complex CPM configurations.
- Full breadcrumb paths on detail, edit, review, and nested record pages.
- Easier to track current location within CPM workflows.
- Clearer, more consistent navigation in the Arc interface.
- More efficient movement between related pages and configurations.
IRM now captures an activity log entry each time a configuration change is made within the Settings page. Log entries include the affected setting, the action performed (enabled, disabled, or updated), the user who made the change, and the exact date and time. The log supports filtering, search, sorting, and CSV export.
Configuration changes in a privacy tool need to be traceable. Whether investigating unexpected behavior or preparing for a compliance audit, the activity log gives you a clear, tamper-evident record of who did what — without reconstructing history from memory.
- Full visibility into who changed IRM settings, what was changed, and when.
- Supports filtering, search, and sorting for efficient log review.
- CSV export for use in compliance reports or external audit requests.
- Maintains secure, traceable configuration management practices.
Administrators can now define a maximum number of selectable options for multi-select dropdown fields in IRM forms. Previously, data subjects could select an unlimited number of options in these fields. The limit is configured directly within the form field settings, providing more controlled and structured form submissions.
Unbounded multi-select fields can produce noisy, hard-to-process submissions. Maximum selection limits bring structure to form data, improve downstream processing, and provide a cleaner experience for data subjects.
- Define a maximum number of selectable options per multi-select dropdown field.
- Improves form validation and data consistency across submissions.
- Prevents excessive or unintended selections during form completion.
- Supports a clearer, more structured experience for data subjects.
A new Quick Action workflow guides users through the full creation and publication of an IRM Intake Form in a single, structured experience. The workflow covers defining form basics, building and customizing form fields, configuring appearance settings, and publishing — all with live preview support at each step. Previously, creating an intake form required manually navigating through multiple separate configuration screens.
Fragmented setup experiences slow down administrators and make onboarding harder. A guided Quick Action removes the guesswork, reduces setup time, and lowers the barrier for teams new to IRM — without removing flexibility for experienced users.
- Create and publish an intake form end-to-end without navigating between separate screens.
- Live preview at each step — see exactly how the form will look before publishing.
- Easier configuration of field customization and appearance settings.
- Faster publishing and sharing of intake forms.