Before you begin, make sure you’re:

☑️ Logged into the Sense Workplace web app

☑️ Assigned administrator permissions

☑️ Familiar with the basics of Screen Designer (see Screen Designer: Overview)

💡 Tip:

This article explains the “why” behind Screen Designer behaviour.

If you only need to create or edit screens, see the task-specific articles instead.

Screen Designer defines how data is structured across your entire Sense HR system.

It determines:

• What information you collect

• Which fields exist in your system

• How information is displayed

• How data is stored, shared, or protected

• How profile templates behave

• How workflows read and write information

• How screens interact with reporting

Understanding these behaviours allows you to:

• Design clean, sustainable data structures

• Avoid accidental data loss

• Predict how screens will behave across templates

• Prevent workflow breakages

• Maintain reliable reporting

• Confidently update your configuration over time

This article is the single authoritative reference on how Screen Designer works internally.

Below are the foundational building blocks of the Screen Designer system.

A screen is a container of fields.

Every page in a profile is a screen.

There are three categories of screen:

​SYSTEM SCREENS

These support essential system logic.

Examples: Overview, Documents, To do, Planner, Leaver details.

System screens:

• Cannot be edited

• Cannot be renamed

• Cannot be deleted

• Do not appear under Screen designer > Screens

• May appear greyed-out inside templates

• Always behave consistently across the platform

​LOCKED SCREENS
These are built by Sense and contain system-protected fields.

Examples: Personal details, Job details, Pay details.

Locked screens:

• Can be partially edited

• Can be renamed

• Cannot be deleted

• Contain fields that cannot be removed

CUSTOM SCREENS

Created by administrators or automatically by workflows.

Custom screens:

• Can be fully edited

• Can be renamed

• Can be deleted (even with data)

• Can have workflow variants

• Can be added to any profile template

Use custom screens for organisation-specific data.

Profile templates determine:
​

• Which screens appear for administrators in a worker’s profile

• The order of those screens

• Which screens store data for that worker group

• What admins see in the sidebar for that user

Profile templates do NOT determine:

• Who can see screens

• Who can edit screens

• Field-level access

• Workflow behaviour

Those belong to Access roles and Variants.

Key behaviours:

• Profile templates cannot be changed for a user once assigned

• Templates define which screens are active, not how they behave

• System screens may appear automatically (e.g., Leaver details)

Fields are the individual data points stored on screens.

There are two types:

EXISTING FIELDS

Fields that already exist in your system.

Reusable across multiple screens.

NEW FIELDS

Fields created when building a screen.

Once saved to a screen, they become reusable Existing fields.

Important behaviour rules:

• Removing a field from a screen removes it only from that screen

• Editing existing field properties updates the field everywhere it is used

• An existing field is permanently deleted only when removed from its final screen

• Permanently deleting a field deletes all data it ever contained

FORM LAYOUT

Use when the screen should store one record per person.

Characteristics:

• Single record

• Vertical layout

• Ideal for static information (e.g., Personal details)

TABLE LAYOUT

Use when the screen should store multiple records per person.

Characteristics:

• Multiple rows

• Each row is an individual record

• Requires at least one column header

• Ideal for historical or repeating data (e.g., training events)

Column headers determine which fields appear as columns in the table view.

Click field > Mark as column header

Rules:

• At least one column header is mandatory

• You can mark as many headers as you like

• Column headers affect reporting readability

• They do not change the order of fields in the “Add record” form

This section covers the most important rules for safe configuration.

When you remove a field from a screen:

• The field is removed from that screen only

• Data stored in that field on that screen is deleted

• The field remains in Existing fields if used elsewhere

• Reports for that screen will no longer show the field

• The field will not appear in workflows referencing that screen

• Workflow steps depending on that field may break

Confirmation flows:

If no data exists:

• One simple confirmation

If data exists:

• Two-step confirmation

• You must type DELETE

An existing field is permanently deleted only when it is removed from its final screen.

Permanent deletion removes:

• All data the field has ever collected

• All reporting references

• All workflow references

• The field from Existing fields

This action cannot be undone.

A screen can only be removed from a template if:

• It does not contain data

• It is not system-protected

• It is not required by workflows

• It is not locked

If a screen contains data, it becomes greyed out and cannot be removed.

Deleting a screen permanently removes:

• All data stored in that screen

• All rows for table screens

• The reporting category

• All workflow variants

• All associated permissions

• Any to-dos tied to that screen

• All references inside workflows

Confirmations:

• No data = simple confirmation

• Data exists = two-step confirmation requiring DELETE

Screens are shared system-wide.

This means:

• Editing a screen updates every template using it

• Editing an existing field updates all screens that use that field

• Removing a field removes its data only from the specific screen

• Removing a screen from a template does not delete the screen

• Deleting a screen removes it from all templates

Workflows may reference:

• Screens

• Fields

• Dropdown options

• Variant visibility

• Required rules

Editing or deleting these structures can break workflows.

Examples of workflow-sensitive actions:

• Deleting fields

• Renaming fields used in conditions

• Changing dropdown values used in routing

• Deleting screens used in workflow steps

• Removing column headers that workflows display

• Editing variants in a way that changes field requirements

Every custom screen automatically creates a reporting category.

Reporting rules:

• All fields in the screen appear as report columns

• Removing a field removes its data and removes the column

• Deleting a screen deletes its entire report category

• Table screens can produce multiple rows per person

• Form screens produce one row per person

• Editing field labels updates column names in reports

The system prevents you from accidentally breaking data structures, workflows, or reporting.
​

A screen or field may appear protected, greyed-out, or locked when:

• It contains data

• It is required by a workflow

• It contains system-protected fields

• It is part of a locked screen

• System rules require it to remain visible

• Deleting it would cause data loss

• Removing it would break workflow routing

• It supports system logic (e.g., job structure)

Screens and workflows can be closely connected.

A workflow may use a screen to:

• Display a form to the employee

• Collect structured data

• Enforce required fields

• Show manager-only or employee-only views (via variants)

• Determine workflow routing based on field values

• Display review or approval content

• Store multiple records (table screens)

Workflows reference:

• The screen name

• Specific fields

• Dropdown values

• Variants

• Required rules

• Visibility and edit permissions

Reporting automatically reflects your screen designs.

Key behaviours:

• Every custom screen creates a reporting category (or subcategory in the Profile Information category)

• Form screens = 1 row per person

• Table screens = 1 row per record

• Field changes update report labels

• Removing a field removes its column and deletes its data

• Deleting a screen deletes the entire report category/sub-category

• Editing column headers (table fields) affects report readability but not the underlying field
​

Reporting is directly tied to Screen Designer.

A clean screen design results in clean, predictable data exports.

These rules explain how Screen Designer interacts with other parts of the system.

A single custom screen may appear in several profile templates.

Behaviours:

• Editing the screen updates it everywhere

• Fields added to the screen appear for all user groups assigned to templates using the screen

• Removing a field removes its data only for that screen, but affects all templates using it

Existing fields are reusable. Editing their properties updates them everywhere.

But:

• Data on each screen is stored independently

• Removing an existing field from one screen does not remove it from others

• Only removing a field from its final screen deletes the field entirely

Example:

An Email field appears on both a Contact Details screen and a Next of Kin screen.

Removing it from Next of Kin does not touch the Contact Details record.

However:

Variants are workflow-specific visibility layers placed on top of a master screen.

Variants:

• Do not create copies

• Do not affect profile visibility

• Do not change field order

• Do not change screen structure

• Do not change reporting

So, hidden fields in variants may still appear in the profile if allowed by Access roles.

System screens contain logic not available in custom screens.

Examples:

• Leaver details

• Planner

• Documents

• To do

• Overview
​

These screens cannot be rebuilt or cloned in Screen Designer.

Some fields on locked screens cannot be removed because the system depends on them.
​

These include fields relating to:

• Employment structure

• Pay and contracts

• Legal identifiers

• Workflow triggers (e.g., start date)

Some library or custom workflows create screens automatically.

These screens:

• Behave like custom screens

• May contain system-connected fields

• May become greyed out in templates

• Should not be deleted without reviewing workflow dependencies

Follow these principles for clean, stable, long-term configuration.

✔ Build reusable screens

If multiple workforce groups need similar information, build one screen and share it.

✔ Keep data structures simple

Avoid adding fields “just in case.” Keep screens purposeful.

✔ Use clear, stable field labels

Labels appear in profiles, workflows, and reports.

✔ Add new fields instead of repurposing existing ones

If a field needs different properties or meaning, create a new field.

✔ Keep table screens lean wherever possible

Limit the number of columns to maintain clarity for users and reporting.

✔ Preview screens regularly

Preview shows you the real, interactive UI, not just the canvas layout.

✔ Be cautious when editing shared screens

One change may affect many profile templates and workflows.

✔ Review workflows before removing fields

Deleting a field or screen may break workflow steps.

✔ Download reports before deleting screens or fields

This preserves historical data before removal.

✔ Document your configuration

Descriptions help future admins understand each screen’s purpose.

Screen Designer controls how information is structured across Sense HR.

Understanding its behaviour ensures safe, predictable, and scalable configuration.

Key takeaways:

• Screens can be shared

• Existing fields are reusable

• Removing a field removes its data for that screen

• Deleting a field deletes its data everywhere

• Screens cannot be removed from templates once they contain data

• System screens and locked screens have protected behaviours

• Workflows may depend on screens or fields

• Reporting reflects your screen structure

• Screen deletion is irreversible

• Visibility belongs to Access roles

• Workflow behaviour belongs to variants

Use this reference whenever you need to understand why Screen Designer behaves the way it does.