Redshift tables: people, profiles & communities

The central table for managing people on Fuse. It defines every user, including their identity, login credentials, profile details, and associations with other entities in the system.

Fuse uses it to: authenticate and authorise access to the platform; personalise content, dashboards and notifications; track progress, activity and engagement; and manage permissions, roles and organisational structure.

Watch out: deleted_at marks deactivated users — filter these out for active-user counts. deprecated_name and deprecated_employee_number are legacy columns; use first_name, last_name and external_id instead. last_activity_at is your best single indicator of recency.

No description was provided in the source. Added here for orientation. Represents a Fuse tenant. It holds instance-level identity, branding and feature-toggle configuration. In a single-tenant connector view this will usually be one row, but it is the anchor for the company_id that appears on almost every other table.

Useful for reporting: users_count gives a headline provisioned-user figure without scanning users. enable_courses and fuse_courses_completeness_enabled tell you whether the learning features that populate user_course_progresses are switched on. Most of the remaining columns are styling and stylesheet-compilation state, of little analytical value.

Organises and delivers actionable reports to managers, supporting oversight, performance tracking and decision-making. It tracks the individual reports a manager uses to review, analyse or share insights about their teams.

Fuse uses it to: generate and display reports for managers in dashboards; support decision-making and performance reviews; let managers track progress and share results; and enable filtering, searching and exporting of reports.

Manages customisable user profile attributes, supporting flexible data collection and personalised experiences. It stores the configuration for each profile field — name, type and validation rules — so the application can collect and display personalised user information.

Fuse uses it to: customise profiles with fields relevant to the organisation (department, location, skills); let admins create, edit and organise profile fields; support dynamic profile forms; and enable filtering, searching and reporting on profile values.

For reporting: label is the human-readable field name you will use as a column header after pivoting. exclude_from_reporting and send_to_analytics tell you which fields are intentionally kept out of analytics — respect them. deleted_at marks retired fields.

Stores and manages user-specific profile information, supporting personalisation, reporting and organisational management. It records each user's responses or selections for custom profile fields such as department, job title or location.

Fuse uses it to: display profile information throughout the application; support filtering, searching and reporting by profile attribute; let users and admins update profile data; and enable personalised experiences, access control and organisational grouping.

Manages the selectable values for custom profile fields, supporting flexible and consistent profile data. It defines the possible values users can choose when filling out a field such as department, location or job title.

Fuse uses it to: present dropdowns, radio buttons and selection lists on profile forms; ensure consistent data entry; let admins create, edit and order the available options; and support filtering, searching and reporting by profile value.

For reporting: join here to get the canonical spelling of an option rather than relying on free-text values in profile_values. It is also the cleanest source for a complete filter list, including options nobody has selected yet.

Delivers flexible, context-aware profile fields. It defines alternative setups for a profile field, allowing the application to present different formats, options or behaviours depending on context — company, region or user type.

Fuse uses it to: customise profile fields for different audiences or use cases; support dynamic profile forms that adapt to user or organisational needs; let admins manage multiple versions of a field; and enable conditional display or validation.

Watch out: if the same underlying field has multiple variants, users may hold values against different variants. Group by profile_field_id rather than variant_id when you want the whole population.

Tailors profile fields to user roles, supporting role-based customisation and data management. It links specific profile field variants to particular roles, controlling which variants are shown or available based on a user's role.

Fuse uses it to: customise profile fields per role so the right data is collected; control visibility and editing permissions per role; support dynamic profile forms; and let admins manage which variants each role can see.

For reporting: mostly configuration rather than analysis, but useful when explaining why a profile attribute is populated for some user groups and blank for others. It also carries default landing-page and default-community settings per role.

Creates and manages user groups, supporting collaboration, engagement and targeted content sharing. Each community is a space where users connect, share content, collaborate and take part in discussions or activities.

Fuse uses it to: organise users into groups for collaboration, learning or social interaction; display community pages with posts, events and resources; manage membership, permissions and privacy; and support notifications, activity feeds and targeted content delivery.

For reporting: type distinguishes general communities from topic communities and learning plan communities — this matters a great deal, because audience metrics such as Topic Audience are calculated against the community attached to the topic. members_count is a quick headline figure but cannot be sliced.

Organises users into communities, supporting access control, collaboration and user management. It is the join table managing user membership of communities.

Fuse uses it to: control access to community content and features; manage permissions, roles and participation; support notifications, collaboration and reporting based on membership; and let admins add, remove or update memberships.

Organises users into groups, supporting group-based features and permissions. It is the join table connecting users to groups so the system can manage group membership for permissions, content access, collaboration and notifications.

Fuse uses it to: determine which users can access group-specific content or functionality; manage group-based permissions and roles; support messaging, collaboration and reporting within groups; and query all members of a group or all groups a user belongs to.

Note: groups and communities are separate concepts. Groups are a permissions construct; communities are the content and collaboration space. Do not use one as a proxy for the other.

Organises and delivers shared content within communities. It tracks the individual items belonging to a community, letting users share, view and interact with content in a community space.

Fuse uses it to: display shared content in community pages and feeds; support collaboration, discussion and resource sharing; let users create, edit and manage community items; and enable searching, filtering and reporting on community activity.

For reporting: this is your bridge from contents to communities. Because a single item of content can appear in several communities, expect fan-out — a view of that content will be attributed to every community it sits in unless you constrain the join or aggregate before joining.

Organises and manages discussions within communities, supporting structured engagement and easy navigation. It defines the subjects or themes around which community members create posts, ask questions or start discussions.

Fuse uses it to: organise posts and discussions by topic; help users find relevant conversations or resources; let admins create and categorise topics; and support filtering, searching and reporting on community activity by topic.

For reporting: this join is what makes "Topic Audience" work — the audience for a topic is the membership of the community the topic is attached to. pinned_at identifies topics deliberately promoted in the community, which is useful when analysing why some topics outperform others.

Controls and customises access to performance assessment features, ensuring proper security and permissions. It defines the rules determining which users, roles or groups can access specific features or data in the performance assessments module.

Fuse uses it to: enforce security and permissions on assessment features; let admins configure who can view or manage assessments; and support dynamic access control so only authorised users can act.

Manages and enforces group-based access to performance assessment features, so only authorised groups can perform specific actions or view sensitive data. It defines which groups can view, edit or administer parts of the performance assessments application.

Fuse uses it to: control which groups can view, edit or manage assessments; support flexible group-based permission management; enforce security on sensitive assessment data; and let admins update rules as the organisation changes.

Manages and enforces user-specific access to performance assessment features. It defines which individual users can view, edit or administer parts of the performance assessments application.

Fuse uses it to: enforce granular access control; let admins configure each user's access level; support permission checks before displaying or allowing actions; and audit and report on access to sensitive assessment data.