Content Experiences & Screens
One layout per application; screens with system-minted six-character codes that BR Profile, Security, Dependent Verification, WorkFlow, and Communication Hub dashboards call to render their banners and dialogs.
Employee & HR Experience · Content Management
Design It Once. Employees See It in BR Profile.
Content experiences, screens, definitions, and components — targeted by audience and date, rendered wherever a screen code is called.
BR Content Management is the print shop for everything employees read inside the platform: the welcome carousel, enrollment welcome content, terms and conditions, review-and-sign disclosures, acknowledgments, consents, the guide tour, the IntelliSuggest introduction, and HR contact tiles. Administrators build a layout per application, screens with a six-character screen code, ordered definitions, and components with media, HTML, targeting, and review or view tracking. BR Profile and every other BR dashboard render that content by asking for the screen code with the employee's record.
Layout → Screen → Definition → Component
Targeted by audience & date
Consents on Text components
Render, review & view logs
Reimagining Employee-Facing Content
"Think of Content Management as two rooms that must stay in sync. Design — layouts, screens, definitions, components, and organizational updates — is the print shop, where administrators work. Render — BR Profile and the other application dashboards — is the newspaper on the doorstep, fetched by screen code for the signed-in employee. Inactive rows and audience mismatches simply hide a widget; there is nothing to publish, because the active flag and the dates are the gate."
Experiences & Screens
One layout per app, screens with codes
Definitions & Components
Media, Text, Tiles, Carousel
Targeting & Dates
Audience, window, consent
Organizational Updates
Announcements on the home page
Analysis
Render logs, reviews, views
4
levels in the content tree — a Content Experience per application, Experience Screens with a system-minted screen code, ordered Definitions, and Components with media, HTML, targeting, and flags
4
view types — Media (image, PDF, video), Text (HTML, where consents live), Tiles (a parent with one level of children), and Carousel — the definition and the component must agree
10
screen codes rendered in BR Profile out of the box: welcome carousel, enrollment welcome, terms, guide tour, review-and-sign and signature disclosures, acknowledgments, consents, IntelliSuggest intro, HR contact
3
things Analysis can show — who was shown what (render logs), star ratings (reviews), and explicit "I viewed this" registrations (views) — as separate metrics
From Layout to the Employee's Screen
Follow a welcome carousel from the experience that holds it, through the screen code that names it, the definitions and components that fill it, the audience and dates that gate it, and the logs that prove it was seen.
A layout per application, a code per screen
A Content Experience is one layout package for one BR application — BR Profile, or the dashboard of Security, Dependent Verification, WorkFlow, Communication Hub, or Content Management itself. Under it, Experience Screens are the views an application will ask for; when a screen is created the system mints a six-character screen code, and that code is the contract: the consuming application calls it with the employee's record and its own application number. Keep the row, keep the widget.
What it delivers
- One experience per application, with name, description, and active flag
- Screens with read-only, system-generated codes and an active switch
- Analytics per experience and per screen — components, renders, reviews
- Jump from a screen straight to its definitions and components
Why it matters
Every employee-facing surface has one owner and one place to change it.
Recreating a screen mints a new code; the consuming application keeps calling the old one until a developer updates the constant — so edit screens, don't replace them.
Definitions order the screen; components fill it
A definition is an ordered block on a screen with a view type — Media, Text, Tiles, or Carousel. Components are the actual content: an image, PDF, or video link; HTML text; a tile with children; a carousel item. Each component carries a sequence, required and length hints, a background or thumbnail from the Document Center, alt text, and the flags that turn on employee widgets — review (star ratings), view (an explicit "I viewed this"), and progress. Tiles nest one level; carousel, media, and text components stand alone.
What it delivers
- Media components with image, PDF, or video link and alt text
- Text components with HTML — the home of consents, terms, and disclosures
- Tiles with child media, text, or tiles; carousels with swipeable items
- Review, view, and required flags per component; sequence and next-order helpers
Why it matters
Content is structured, not pasted — so it renders the same in every application that calls it.
Video is a link, not an upload; a consent lives only on a Text parent whose consent type exists on the consent master.
Who sees it and when
Every component can be restricted by audience — access control, business unit, location, division, company, department, location group, gender, or named employees — and by a visible-from and visible-to window. At render, the engine filters against the employee's record and benefit area, drops what does not apply, strips the targeting fields from the employee payload, and signs the Document Center URLs. A child component's audience must stay inside its parent's; a restricted component needs at least one real filter.
What it delivers
- Employee-restricted components with SELOPT dimensions (asterisk means everyone)
- Date-restricted components with visible-from and visible-to
- Consent components on Text with a consent type from the consent master
- Render-time filtering — targeting and dates never reach the browser
Why it matters
An executive slide, a plant-closure notice, or a plant-specific banner is one component, not a second layout.
Inactive rows, a missed audience, or an out-of-window date all produce the same honest result: the widget hides.
Announcements outside the tree
Organizational Updates are the home-page announcement carousel — featured items, videos, policy notes, plain announcements — with a title, body, type, priority, media or link, a display order, a "published by" label, start and end dates, and optional audience targeting. They are not screens in the content tree; BR Profile fetches them for the signed-in employee through their own call, so a department-only notice reaches that department and nobody else.
What it delivers
- Featured, video, policy, and announcement types with priority and display order
- Start and end dates with validation, and the same audience dimensions as components
- Media file rules per type; links for video messages
- Employee-scoped retrieval for the home carousel
Why it matters
Campaigns, policy notes, and leadership messages go out without touching the enrollment screens.
"Published by" is a label on the update, not an approval — the active flag and the dates are what gate it.
Proof it was seen, and what employees thought
Three things happen on the employee side and each has its own record. When a screen with a view-flagged component renders, a render log row is written automatically. When an employee explicitly registers a view, a content view is stored once per person. When an employee rates a component, a review is stored — one per person per component, editable only by its author. The Analysis pages read those back with KPIs, trends, drill-downs, and rating charts for any period.
What it delivers
- Render logs — who was shown what, by component, user, and trend
- Content reviews — star ratings and text, with rating distributions
- Content reviews — explicit registrations with duration buckets
- Period filters and drill-down tables on every chart
Why it matters
"Did employees see the terms?" and "did they like the welcome?" are answered from data, not assumption.
Render logs and explicit views are different metrics — every fetch versus a deliberate "I viewed this" — and the pages keep them apart.
Core Capabilities of Content Management
The structured content model, its targeting, and its evidence — built by administrators, rendered by BR Profile and every BR dashboard, and measured on the Analysis pages.
Definitions & Components
Ordered Media, Text, Tiles, and Carousel blocks filled with images, PDFs, video links, HTML, and one-level tile children — with sequence, required, review, view, and progress flags.
Audience & Date Targeting
Component-level audience over company, location, department, division, business unit, access control, or named employees, plus visible-from and visible-to windows — filtered at render and stripped from the payload.
Consents, Terms & Disclosures
Text components carrying a consent type from the consent master power the terms dialog, review-and-sign disclosures, signature disclosures, acknowledgments, and the employee's consents view.
Organizational Updates
Home-page announcements — featured, video, policy, announcement — with dates, priority, order, media, and audience, fetched per employee outside the screen tree.
Render, Review & View Analysis
Automatic render logs, one-per-person explicit views, and one-per-person star reviews with KPIs, trends, rating charts, and drill-downs by period.
Athena inside Content Management
"Who Saw the Terms?" Answered from the Logs
Athena reads the content tree and the analysis tables. For administrators it explains why a component is hiding for an employee — inactive row, date window, or audience — and turns render, view, and review data into plain answers. For employees, Athena explains a consent or a disclosure in their own context before they accept it, and helps them find the guide again.
- "Why can't Jane see the OE slide?" — the active flag, the visible-from date, and the audience filter checked in order, with the one that hid it
- Coverage of consents — which employees have rendered the terms and which have not, by population
- Ratings explained — what the lowest-rated component says in its reviews, and which version it was
- Employee help — "what am I agreeing to?" answered from the consent text and the employee's enrollment
- Change safety — which applications call a screen code before an administrator edits or retires it
Why is the OE 2027 welcome slide not showing for Jane Doe?
AthenaThe component is active and Jane is in its audience, but its visible-from date is 10/15 and today is 09/17 — the render filter hid it by date. The five other carousel slides rendered for her at 08:14 this morning and a render log row was written for each view-flagged one.
ActiveYes · component and screen
Visible window10/15 – 11/15 · not yet
Show her render logChange the datesPreview as Jane
Has she accepted the enrollment terms?
AthenaThe terms screen rendered for her on 09/02 and she registered an explicit view the same day; the consent component "Electronic delivery" is recorded as accepted on 09/02 at 09:41. Nothing further is required until the terms version changes.
Ask Athena about this screen…
What Content Management Changes
One place to change a screen
Welcome, terms, disclosures, consents, and tour content live in a tree, not in code.
The right content for the right employee
Audience and date filters at render — one component, many populations.
Consents are content, with evidence
Text components carry consent types; acceptance and views are logged per employee.
Announcements without developers
Organizational updates go to the home carousel with dates, order, and targeting.
Seen, viewed, rated — measured
Render logs, explicit views, and star reviews answer "did they see it?" separately.
Stable contracts
Screen codes are the interface every dashboard relies on; edits keep the code, so nothing breaks.
Where It Shows Up in the BR Experience
Content Management is an administrator application; employees never open it. Administrators build experiences, screens, definitions, components, and organizational updates on SAP BTP and AWS, and upload media through the Document Center. BR Profile and each application dashboard render the results by screen code, and the Analysis pages read back what happened.
- Admin: content experiences and screens — one layout per application, screens with generated codes, analytics per experience and screen
- Admin: definitions and components — ordered blocks, component editor with media, HTML, targeting, dates, consent, and review/view flags
- Admin: organizational updates — announcement editor with type, priority, order, media, dates, and audience
- Employee: BR Profile and the mobile app — welcome carousel, enrollment welcome, terms, review-and-sign and signature disclosures, acknowledgments, consents, guide tour, IntelliSuggest intro, HR contact — all rendered by code
- Admin: analysis — render logs, content reviews, and content views with KPIs, trends, rating charts, and drill-downs
Take control of what employees read
Bring your current welcome text, terms, and a disclosure. We'll build the experience, mint the screen codes, target one slide to one population, render it as an employee, and show the render and review data behind it.
Screen-code contract
Render-time targeting
Consent evidence
Content Management FAQs
Every employee-facing content surface inside the platform — the welcome carousel, enrollment welcome content, terms and conditions, review-and-sign and signature disclosures, acknowledgments, consents, the guide tour, the IntelliSuggest introduction, HR contact tiles, and home-page organizational updates — designed by administrators and rendered by BR Profile and the other BR dashboards.
Each Experience Screen has a system-generated six-character screen code. BR Profile (and each application dashboard) calls that code with the employee's record and its own application number; the engine returns the active, in-window, in-audience components with signed media URLs. Inactive rows or audience mismatches simply hide the widget.
No. The active flag on the layout, screen, definition, and component — together with visible-from and visible-to dates — is the gate. Approval workflows apply to messages in Communication Hub and to documents in the Document Center, not to layout content.
Yes. Components and organizational updates can be restricted by access control, business unit, location, division, company, department, location group, gender, or named employees, and by a date window. Filtering happens at render time and the targeting fields never reach the browser.
A consent is a Text component with a consent type that exists on the consent master. It renders inside the terms, review-and-sign, signature, acknowledgment, and consents screens, and each employee's acceptance, explicit view, and rating are recorded for the Analysis pages.
No. Employees only render content in BR Profile; the Content Management application is administrator-only. Reviews are per person and editable only by their author.
Render logs (who was shown what, automatically), content views (explicit "I viewed this" registrations, once per person), and content reviews (star ratings, one per person per component) — each with KPIs, trends, rating charts, and drill-downs for any period.
Structured Content, Rendered Everywhere
Experiences, screens, definitions, and components with targeting and evidence — one tree that every BR surface reads by code.