Admin Configuration Guide

Audience: privacy, marketing, and platform admins configuring Consent Management inside Relyance. No coding required for anything in this guide.

Domain Analyzer

The Domain Analyzer is the crawler that discovers tracking technologies on your domain or mobile app and feeds everything else in Consent Management. It matters for three reasons: it's your data-discovery layer (what's actually collecting data, and how), it's the evidence base for the tracking-technology inventory regulators expect you to maintain, and it directly powers what the Consent Agent later blocks or allows.

How a scan works, stage by stage:

Site map identification - the analyzer reads your XML sitemap (if available) to scope the crawl beyond just the homepage.
Recording tracking technologies - it navigates individual pages and inventories every tracking mechanism it finds (cookies, pixels, local/session storage, scripts, fingerprinting).
Evaluating purpose of processing - it analyzes what each script/technology actually does and what data it collects to classify intent (analytics, advertising, functional, UX).
Auto-categorizing by vendor - technologies are grouped by function and mapped to known vendors where recognizable (e.g., Google Analytics, Meta Pixel).
Publishing results - findings are sent to Tracking Technology Management for your team to review.

Adding a domain:

Click Add Domain.
Enter the full URL, including protocol (e.g., https://www.example.com/).
Associate it with a Business Entity - required before the scan can run.
Click Add - this automatically kicks off the first scan.

Scanning behind authentication

For domains where meaningful tracking technology only appears after login (e.g., a customer portal or an authenticated app shell), the Domain Analyzer can crawl behind that login wall. Set this up in the Authentication step of the Add/Edit Domain wizard:

Auth method: HTTP Basic Auth, or Form Recording - record a login flow with the Chrome DevTools Recorder panel and upload the exported JSON; Relyance replays it via a headless browser to sign in before crawling. Cookie-paste and header/token auth appear as options in some views but aren't functional yet, and SSO/SAML and OAuth logins aren't supported - those flows can't be captured and replayed as a stored credential.
Login URL: the page hosting the login form. Used for Basic Auth; for Form Recording, the URL comes from the first step of the recording itself.
An optional credential expiry date, for your own tracking of when a credential should be rotated. This is informational only today - Relyance doesn't block scans or prompt for re-entry once this date passes, so don't rely on it as an automated reminder.
Save & Test runs a one-off authentication check immediately; you can also save credentials untested and let the next scan verify them.
Credentials are never stored as plaintext or returned by the API - only a reference to a secret-manager entry is kept on the domain record. Viewing a saved credential again requires an explicit "reveal" action and edit permission.
Authentication status (Untested / Testing / Passed / Failed) shows on the Domains grid, with a failure reason on hover. Every rescan of a credentialed domain reuses the saved credentials automatically - you don't need to re-enter them each time.

This applies to domains only, not mobile app digital properties. If you need to hand a login recording to your engineering team to capture, see the Technical Implementation Guide.

Scheduling automatic scans

By default, a domain only scans when you add it and whenever you click Rescan manually. To have Relyance rescan on a recurring basis, set a cadence in the Scheduling step of the Add/Edit Domain wizard:

Frequency: Manual (default), Weekly, or Monthly.
Weekly: pick a day of the week. Monthly: pick a day of the month - a 31st clamps to the 28th/29th in shorter months rather than rolling into the next month.
Time of day: in 30-minute increments.
Time zone: captured automatically from your browser and shown for reference - it isn't manually editable, and stays anchored to whichever browser originally set it, so reviewing a colleague's schedule shows their time zone, not yours.

A newly saved schedule targets its next real occurrence, not an immediate scan - saving a "Monday 9:00 AM" schedule on Monday afternoon runs the following Monday. Scheduled runs show up in the domain's Scan History with a distinct "Scheduled" trigger (manual scans show who triggered them instead). Editing a schedule takes effect within seconds, and an extra manual scan or rescan doesn't reset or shift the recurring cadence.

Scan notifications

Configure who hears about scan results in the Completion step of the same wizard:

Add one or more recipients (existing Relyance users on your tenant, up to 50) - this list starts empty by default, so no one is notified until you explicitly add recipients.
Independent toggles for notify on scan complete, notify on scan failure, and show in-app notifications - all on by default once recipients are added.
Notifications fire per scan, not as a daily/weekly digest, for both manual and scheduled scans, by email and/or an in-app bell notification depending on your toggles. There's no Slack channel for this today.
These are per-domain settings, separate from any personal notification preferences a user has elsewhere in Relyance - being added as a recipient on a domain is what determines whether that person hears about its scans.

Allowing the Relyance Domain Analyzer IPs

If your organization runs a WAF, CDN-level bot protection (e.g., Cloudflare), or an IPS/IDS, it may block the analyzer's crawl before it gets meaningful results. Symptoms: the scan fails outright, completes but reports zero tracking technologies found, or the site screenshot doesn't appear in the Interface Builder preview.

Fix: allowlist these IP addresses in your security tooling:

34.82.181.167
35.199.149.43
34.145.53.165
8.229.95.221
34.83.113.133

Tracking Technology Management

This is the central page for reviewing, categorizing, and acting on everything the Domain Analyzer finds. Approve/disregard decisions made here directly control what the Consent Agent enforces on your live site.

Summary counts: New (discovered, not yet reviewed), Not Found (previously seen, absent from the most recent scan), Approved, Disregarded.

Views: Discoveries (default - all active items), Approved, Disregarded.

Filtering: free-text search plus filters for Vendor, Purpose/Category, Source Domains, and Domains.

Table columns: checkbox (bulk select), Vendor, Purpose/Category, Source Domains, Domains, Date Found.

Per-item actions (via the row's expand arrow or the ⋮ menu): Approve, Disregard, Edit.

Bulk actions: select multiple rows and Approve, Disregard, or Bulk Edit - a two-step flow: (1) choose the field to change (Processing Activities, Status, or Third Party - for multi-value fields, choose Add / Remove / Replace values), then (2) review and confirm before it applies to every selected item.

Recommended review workflow: review new discoveries → verify or correct auto-categorization → assess each against your consent/privacy requirements → Approve or Disregard → repeat periodically, since sites change and new trackers get added over time.

Resource URL Patterns. Each tracking technology has a Resource URL Pattern field - the URL pattern matched against a script's src attribute - which is what the Consent Agent actually checks at runtime. If a technology is being blocked or allowed incorrectly, this field is usually the reason; edit it from the technology's edit dialog, then Publish the change for it to take effect live.

Proactive Tracking Technology Control

A domain-level setting (Domain Detail → Agent tab → Details) governing what happens to a tracking technology the agent detects but that isn't yet categorized/approved in Relyance. Three options:

Option	Behavior	Best for
Always Allow	Unrecognized technologies load unrestricted, regardless of consent state; the agent only actively controls what's explicitly approved.	Organizations with other script-management controls already in place, or that prefer a less restrictive default.
Only Allow if Accepted All (recommended)	Unrecognized technologies load only if the visitor has accepted every purpose category; anything short of full acceptance blocks them.	Most organizations - balances compliance with not over-blocking.
Never Allow	Unrecognized technologies are blocked outright, no matter what the visitor consents to.	Highly regulated or strict-compliance environments - but requires keeping your approved list comprehensive, or you risk blocking legitimate functionality.

Navigation: Settings → Consent Management → Domains → select a domain → Behaviors tab.

Region Groups define what should happen, legally and behaviorally, for visitors from a given jurisdiction. Every domain has a Global group - always present, cannot be deleted, and acts as the catch-all ("like an else clause") for any jurisdiction not claimed by a more specific group. Add additional groups scoped to specific countries and, where relevant, states/provinces (e.g., a US group narrowed specifically to California for CCPA). A given jurisdiction can only belong to one Region Group per domain.

Consent Model (per Region Group): Implied Consent, Opt-out, Opt-in, or No Choice - see the Legal and Compliance Guide for what each means legally, and the Regional and Jurisdiction Reference for market-standard, jurisdiction-specific configuration patterns.

Banner visibility/interaction: a Show Banner toggle, and a Require Interaction toggle (only available when Show Banner is on) that forces the visitor to make a choice before continuing.

Interface (Consent Template): a dropdown selecting which Interface Builder template renders for this region - click Open to jump directly into editing it.

User Action Behaviors: configure what counts as a consent action for three implicit triggers - banner close, page scroll, page click - each set to No Action, Deny All, or Accept All. In stricter opt-in jurisdictions, these should generally be set to No Action (see the Legal and Compliance Guide for why).

Global Privacy Control (GPC): a master GPC Integration toggle for GPC detection/response, an "Honor GPC for all purposes" toggle (recommended default), and a "Customize by purpose" link revealing Advanced GPC Settings - where Strictly Necessary purposes always stay active regardless of GPC, and every other purpose can individually be set to Honor GPC or Ignore GPC.

Consent Log (within this tab): an Enable Consent Logging toggle, plus Advanced Storage Settings ("Show Advanced") with two data-minimization checkboxes - Anonymize IP addresses (removes the last octet) and Store browser type only (not the full user-agent string). An Open Consent Log button jumps to the log viewer. Full detail in Consent Logs and Reporting.

Interface Builder

The Interface Builder is where you design everything a visitor actually sees: the banner, preference center, opt-out widget, and policy page.

Configurable: title, description, Accept All / Reject All / Manage Preferences / Close button text and aria-labels (each independently shown/hidden), links (privacy policy, cookie policy, DSR portal, preference center), text/background colors (with separate dark-mode variants), focus-indicator color, and full per-button styling (colors, border, border radius).

Link tokens: type {dsr-portal}, {privacy-policy}, {cookie-policy}, or {preference-center} directly into the description text, and the Interface Builder resolves them into live links at render time (paired with a Link Label field you configure). If a token is used without its label/href configured, the builder shows a bright inline "Missing link and/or label" warning while you're editing - a validation cue, not something visitors ever see.

Embedding a "Manage Preferences" link inline: put the {preference-center} token anywhere in the Banner Description text and set the Preference Center Link Label. Example: "You can {preference-center} at any time" renders as "You can [Change your settings] at any time." If the label is missing due to a config error, the system falls back to "Settings" so the banner still functions.

Preference Center

Layout: Modal or Drawer.

Configurable: title, description, "Always Active" label (shown for purposes that can't be turned off), all button text/aria-labels/visibility (Accept All, Reject All, Close, Save), colors (with dark variants), focus indicator, primary/secondary button styling, and per-purpose localization overrides.

Each purpose renders as a card with a real on/off toggle - except purposes marked "Always Active" or using the No Choice consent model, which render a disabled, permanently-on switch instead, and purposes with GPC honoring enabled, which are disabled for manual toggling since the GPC signal controls them. If Show Technologies is on, each purpose card gets an expandable section listing the actual tracking technologies mapped to it (name, provider, type, expiration) - all field labels here are independently editable/localizable.

If GPC is honored, an optional GPC opt-out confirmation message can be shown inside the preference center itself (fully styleable), confirming to the visitor that their signal was respected.

A small floating confirmation badge (not a Do-Not-Sell link) shown after a GPC signal has been detected and honored - e.g., "Your Privacy Choices have been respected." Configurable: show/hide, message text, text/background/border colors and border width. It only renders once all required fields are filled in.

Policy page

Renders a full tracking-technology/cookie policy page (not a modal): title/description, "What Are Tracking Technologies," "How We Use Tracking Technologies," a per-purpose table of tracking technologies (name, description, vendor, type, expiration), "Your Rights and Choices," "Third-Party Services," "Updates to This Policy," "Contact Information," and Policy Styles (font, background color, text color). Every section's text is independently editable and localizable; the technology table itself is driven by your live tracking-technology inventory, not manually typed - fix a wrong row in Tracking Technology Management, not on this page. Only available on Domain-type templates, not Mobile.

Implementing a Tracking Technology Policy on your policy page - step by step:

Make sure your prerequisites are in place first: the domain has been added and scanned (see Domain Analyzer above), and the technologies you want disclosed are Approved in Tracking Technology Management.
Go to Consent Management → Templates, then open the Consent Interface Template you want to edit (or create a new one - Template Type must be Domain). You can also reach the same template from a specific domain: Domains → select the domain → Behaviors tab → pick a Region Group → Interface (Consent Template) → Open. Each Region Group on a domain points at one template, so if different Region Groups use different templates, repeat these steps for each one that needs its own Policy page content.
In Interface Builder, toggle to the Policy sub-interface (alongside Banner, Preference Center, and Opt-Out Widget) and fill in each section listed above. Leave the technology table alone - it's auto-populated.
If you support multiple languages, use Manage Locales to add each one; Smart Translation drafts a translation to refine, and Sync re-translates in bulk later.
Copy changes save automatically as you edit. To push the template - including this Policy page - live to a domain, go to that domain's Agent tab and click Publish. Until then, changes stay in draft and aren't visible to site visitors.
(Optional) Link to the page from your Banner or Preference Center description using the {cookie-policy} link token (see Link tokens below), or add a plain link wherever you embed the page (e.g., your site footer).

The technology table updates automatically going forward as you approve or disregard items in Tracking Technology Management - no republish needed for table changes; you only need to Publish again after editing the page's written copy.

For the code needed to actually embed the published page on your website, see the Technical Implementation Guide.

Branding and theming

A shared font family applies across the banner and preference center. Every surface supports Light and Dark themes - nearly every color field has a paired dark-mode variant that's automatically used when dark theme is active. The Interface Builder includes a contrast-ratio check that warns you if a text/background color combination doesn't meet accessibility standards. There is no free-form custom-CSS injection field - all styling goes through the discrete color/font/border controls described above.

Editing and translation tools

In-context editing: double-click any text element directly in the live preview to edit it inline; changes reflect instantly.
Smart Translation: when you add a new language, an internal translation service auto-drafts translated copy for you (preserving proper nouns and numbers) - you can then refine it. A confirmation banner appears once a locale has been added.
Manage Locales: add a locale, delete a locale, set the default locale, or sync (re-translate) locales in bulk from the source language - sync runs as a background job with its own progress indicator since it's a batch operation across all your text fields.

Protecting RoPA accuracy: editing a purpose's display title in the builder updates the customer-facing Consent Name only - it does not change the internal Processing Activity Name used for your Records of Processing Activities. This is intentional: marketing/brand can freely edit banner wording without corrupting legal's underlying records.

Once your engineering team has wired up login/logout callbacks (see the Technical Implementation Guide), you'll see two changes in the Consent Log views: a User ID column in the list view (populated for logged-in visitors, blank for anonymous ones), and a Consent History tab in the detail view showing all prior consent decisions for that user across every device they've used (or, for anonymous records, history scoped to that device).

Permissions

Viewing and exporting Consent Logs requires the Consent Settings viewing permission on a user's Relyance role. If a teammate can't see the Export button or the Consent Logs page, that's the permission to check first.

Optional/tenant-gated features

A few capabilities mentioned across these guides are enabled per-tenant rather than universally on:

Mobile app consent management - mobile-specific tracking-technology fields, a dedicated settings section, and mobile app configuration views.
Consent Management analytics dashboard - a top-level dashboard with region-based visualizations (maps, trend charts, tracker-discovery metrics).

If you don't see one of these in your instance and expect to need it, check with your Relyance CSM or account team.