Cookie Consent

A modern, drop-in GDPR-style cookie consent banner for OutSystems Reactive Web. It shows a first-visit banner with equally-prominent Accept / Reject / Customize options, remembers the user's choice, lets them change or withdraw it any time, records every choice for accountability, and gives you a simple HasConsent() check to gate your own tracking scripts.

Platform: OutSystems 11 (O11) · Type: Reactive Web · Curation target: Community / Trusted

⚠️ Important: this is a tool, not legal advice

This component helps you implement a consent mechanism. It does not, by itself, make your app compliant with GDPR, ePrivacy, CCPA, or any other law, and nothing here is legal advice. You remain responsible for knowing which cookies and scripts your app uses, writing an accurate cookie/privacy policy, choosing the correct legal basis, and confirming your setup with your own legal or data-protection advisor. Use this component as the UI and plumbing; the compliance decisions are yours.

1. Overview

Cookie Consent puts a configurable consent banner on every screen of your app. On a user's first visit it asks how they want their data handled; it then stores that choice so it doesn't ask again until your policy changes or the choice expires. You gate your non-essential scripts (analytics, marketing, etc.) behind a simple consent check, and every choice is optionally logged to an entity for your records.

Key features

• First-visit banner with Accept All, Reject All, and Customize — all equally prominent (no dark patterns).
• Per-category preferences: Necessary, Functional, Analytics, Marketing.
• Remembers the choice across sessions; re-asks on policy change or after expiry.
• HasConsent() check and an OnConsentChanged event to gate your tracking.
• "Cookie settings" re-open so users can change or withdraw consent any time.
• Optional consent audit log (what was consented to, when, and against which policy version).
• Modern floating card + preferences modal, fully responsive, reduced-motion aware.
• One-variable theming — recolor the whole component to match your brand.

2. The principle behind it

Showing a banner is not the same as complying. The real requirement is that non-essential cookies and scripts must not run until the user consents. So the important part of this component isn't the banner — it's the consent gate. Use HasConsent("analytics") (or the OnConsentChanged event) to decide when to initialize your tracking, and don't fire those scripts until consent is granted.

Two rules the component is built to respect: Reject must be as easy as Accept (the buttons share one style and size), and users must be able to withdraw consent as easily as they gave it (the re-open link).

3. Compatibility

4. Installation

1. Install Cookie Consent from the Forge (or the .oap via Service Center).
2. In Manage Dependencies, select the module and check the CookieConsent block, the HasConsent and OpenPreferences actions, and the CookieCategory static entity.
3. Apply and publish.

5. Setup in three steps

1. Place the banner app-wide. Drop the CookieConsent block on your app's Layout (or the common layout of your main flow) so it shows on every screen. Set PolicyURL to your cookie/privacy policy page.
2. Add a re-open link. Put a "Cookie settings" link in your footer and set its On Click to call OpenPreferences — this is how users change or withdraw consent.
3. Gate your scripts. Wherever you initialize analytics or marketing tags, guard them with HasConsent("analytics") (etc.), and/or handle the block's OnConsentChanged event to turn tracking on or off.

6. Reference

CookieConsent block

HasConsent action

OpenPreferences action

No parameters. Reopens the preferences panel showing the user's current choices, so they can change or withdraw consent.

7. Categories

The component ships four standard categories via the CookieCategory static entity:

Necessary requires no consent under most regimes and is always granted; everything else defaults to off until the user opts in. (Custom categories are a planned enhancement.)

8. How re-consent works

The banner reappears automatically when any of these is true: the user has never chosen; the stored PolicyVersion differs from the current one (so bumping the version re-prompts everyone after a policy change); or the stored choice is older than ExpiryDays. Otherwise the banner stays hidden and the app uses the remembered choice.

9. The consent audit log

When EnableAudit is on, every choice writes a ConsentRecord with: a generated consent id, the categories granted, the policy version, the action taken (Accept All / Reject All / Custom / Withdraw), and the timestamp. This gives you an accountability trail if you're ever asked to demonstrate consent. By design it stores no IP address or personal identifiers — keep it that way unless you have a specific, documented reason and legal basis to add them.

10. Gating your tracking — example

// Only initialize analytics once the user has allowed it
If HasConsent("analytics")
   → run your analytics init logic

Or react to changes at the moment the user decides:

Handle CookieConsent.OnConsentChanged(GrantedCategories):
   If HasConsent("marketing") → enable marketing tags
   Else                       → disable them

Never place your tracking so that it runs before this check.

11. Styling and theming

The banner and preferences panel ship with a modern look — a floating card, pill buttons, a frosted modal, subtle entrance animation, full responsiveness, and a reduced-motion fallback. All colors are driven by CSS variables, so you can rebrand the whole component by overriding a single value in your app's theme:

/* Match the banner to your brand color */
.occ-banner, .occ-panel { --occ-accent: #7c3aed; }

The available variables are --occ-accent, --occ-accent-hover, --occ-surface, --occ-text, --occ-muted, and --occ-border. Override any of them to fit your design system; leave them alone for the default green theme.

12. Troubleshooting / FAQ

The banner shows every visit.Make sure the block is placed once on the shared Layout (not re-mounted per screen in a way that resets state), and that the client variables aren't being cleared. Also check ExpiryDays isn't set very low.

The banner never shows.A stored choice already exists for the current PolicyVersion. Bump PolicyVersion (or clear the browser's site data) to see it again.

My analytics still runs after Reject.The component doesn't stop scripts on its own — you must gate them with HasConsent / OnConsentChanged. Anything not behind that check will still run.

Users can't change their mind.Add the "Cookie settings" link calling OpenPreferences, ideally in the footer on every page.

Preferences open but show default choices instead of the saved ones.This means the current consent isn't being read when the panel opens. Ensure OpenPreferences refreshes the panel's category state before showing it.

13. Best practices

• Keep Accept and Reject visually equal — don't hide or de-emphasize Reject.
• Default all non-necessary categories to off.
• Gate every non-essential script; treat consent as required before loading.
• Bump PolicyVersion whenever your cookie usage changes.
• Keep the audit log free of personal data.
• Have your policy and setup reviewed by someone qualified — this tool is the mechanism, not the compliance.

14. Version history

15. License

Published on the OutSystems Forge as open, reusable code. Free to use and adapt in your OutSystems projects.