live_group_profile Table

Table Reference/live_group_profile

The live_group_profile table stores real-time metadata for Connect collaboration groups in the Collaboration module. Before querying it, know that records are automatically managed by the Connect framework and direct manipulation can break real-time messaging functionality.

What This Table Is

The live_group_profile table maintains real-time metadata for Connect collaboration groups, storing group information like member counts, activity status, and group configuration. Each record represents a single collaboration group's current state, updated continuously as users join, leave, or interact within the group.

This table belongs to the Collaboration module and supports the end-to-end Connect messaging experience. It works alongside the messaging infrastructure to provide group discovery, member management, and real-time status updates that power the Connect chat interface.

The table extends the base sys_metadata table and has relationships with live_group_member for member tracking and live_message for message history. Groups can be public, private, or system-generated based on business context like incident response teams.

In large enterprises, this table typically contains hundreds to low thousands of records, with high read volume but relatively low write volume. Performance is optimized for real-time lookups by group ID and active status, making it suitable for frequent polling by Connect clients.

When You'll Script Against This Table

You'll primarily script against live_group_profile in Business Rules that respond to group lifecycle events, Script Includes that provide Connect integration APIs, and Scheduled Jobs that clean up inactive groups. Most access happens in global scope, though scoped applications can query groups they own or have access to.

Access requires the connect_user role for basic operations, with connect_admin required for administrative functions like creating system groups or modifying group security settings. Record-level security restricts access to groups where the user is a member or has explicit permissions.

Auto-creating incident response groups when P1/P2 incidents are opened
Querying group membership for custom notification logic
Building custom Connect widgets that display group activity
Archiving inactive groups based on last activity timestamps
Integrating with external chat systems by syncing group metadata
Generating reports on collaboration group usage and adoption
Implementing custom group discovery and recommendation engines

Table Gotchas

⚠️

Never delete live_group_profile records directly. Use the Connect API or set state to 'archived' - direct deletion can orphan messages and break member relationships.

The member_count field is automatically maintained by triggers and may not reflect real-time changes during bulk member operations

⚠️

Group names are not guaranteed unique across the system. Always query by sys_id or use name + context filters when precision matters.

The last_activity timestamp updates asynchronously and may lag behind actual message activity by several minutes
Queries filtering by description or topic fields without additional indexes can be expensive on large datasets

⚠️

Private groups have strict ACLs that prevent non-members from reading even basic metadata. Always check access before querying in user context.

System-generated groups (like incident response teams) have special lifecycle rules and shouldn't be modified manually

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The live_group_member table is the most important relationship, storing individual user memberships and roles within each group. Every group query typically involves checking member relationships for access control and notification targeting. The live_message table contains the actual conversation content, with each message referencing back to the group profile.

Business context comes through relationships with task records (when groups are created for incident response), sys_user_group records (for department-based groups), and kb_knowledge records (for knowledge-sharing groups). These relationships enable automatic group creation and membership management based on business workflows.

The sys_user table connects through the created_by field and member relationships, while live_group_notification tracks notification preferences and delivery status for each group member.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
name	string	Group Name	Display name of the collaboration group. Not guaranteed unique across the system, and can be changed by group administrators.
description	string	Description	Optional description of the group's purpose. Often empty for system-generated groups but required for user-created groups.
state	choice	State	Group lifecycle state: 'active', 'inactive', 'archived'. Only active groups appear in Connect interfaces and receive new messages.
type	choice	Group Type	Group classification: 'public', 'private', 'system'. Determines visibility rules and who can join without invitation.
member_count	integer	Member Count	Cached count of active members. Updated by triggers but may be temporarily inconsistent during bulk operations.
created_by	reference	Created By	User who created the group, or 'system' for auto-generated groups. Group creator automatically becomes admin unless overridden.
last_activity	glide_date_time	Last Activity	Timestamp of most recent message or member activity. Updated asynchronously and may lag behind real activity by minutes.
context_table	string	Context Table	Table name when group is created for business context (e.g., 'incident', 'change_request'). Empty for standalone groups.
context_id	string	Context Record	Sys_id of the business record this group supports. Used with context_table to link groups to incidents, changes, etc.
topic	string	Topic	Optional topic or hashtag for group categorization. Used for group discovery and filtering in Connect interfaces.
avatar	string	Avatar	URL or identifier for group avatar image. Falls back to default system avatar if empty or invalid.
is_pinned	boolean	Pinned	Whether this group appears at the top of group lists. Typically set for high-priority or frequently-used groups.
auto_add_members	boolean	Auto Add Members	When true, automatically adds relevant users based on context (e.g., incident assignment group). Only applies to system groups.
notification_enabled	boolean	Notifications Enabled	Master switch for group notifications. When false, no member receives notifications regardless of individual preferences.
allow_external	boolean	Allow External Users	Whether users without Connect licenses can be added to this group. Requires special licensing and security approval.
retention_days	integer	Message Retention Days	Number of days to retain messages before archival. Zero means indefinite retention. Overrides system defaults.
max_members	integer	Maximum Members	Optional limit on group membership size. Zero or empty means no limit. Enforced when adding new members.
parent_group	reference	Parent Group	Reference to parent group for hierarchical group structures. Used in enterprise scenarios with nested team organization.
external_id	string	External ID	Identifier from external chat systems for integration scenarios. Must be unique within the external system context.

Common Queries

Get all active collaboration groups

// Most basic query - gets active groups user can access
var gr = new GlideRecord('live_group_profile');
gr.addQuery('state', 'active');
gr.orderBy('name');
gr.query();

while (gr.next()) {
    gs.info('Active group: ' + gr.getValue('name') + 
            ' (Members: ' + gr.getValue('member_count') + ')');
}

Find groups by type and recent activity

// Business scenario: find active public groups with recent activity
var gr = new GlideRecord('live_group_profile');
gr.addQuery('state', 'active');
gr.addQuery('type', 'public');
gr.addQuery('last_activity', '>=', gs.daysAgoStart(7)); // Active in last week
gr.orderByDesc('last_activity');
gr.query();

while (gr.next()) {
    gs.info('Recent group: ' + gr.getValue('name') + 
            ' - Last activity: ' + gr.getDisplayValue('last_activity'));
}

Get incident response groups for specific user

// Real-world: find incident groups where user is member
var userId = gs.getUserID();
var gr = new GlideRecord('live_group_profile');
gr.addQuery('context_table', 'incident');
gr.addQuery('state', 'active');
// Join to member table to check membership
gr.addJoinQuery('live_group_member', 'sys_id', 'group')
  .addCondition('member', userId)
  .addCondition('state', 'active');
gr.query();

gs.info('User is in ' + gr.getRowCount() + ' incident response groups');

Count groups by type using GlideAggregate

// Aggregate count of groups by type for reporting
var ga = new GlideAggregate('live_group_profile');
ga.addQuery('state', 'active');
ga.addAggregate('COUNT');
ga.groupBy('type');
ga.query();

while (ga.next()) {
    var groupType = ga.getValue('type');
    var count = ga.getAggregate('COUNT');
    gs.info('Group type "' + groupType + '": ' + count + ' groups');
}

Wrong way vs right way to check group membership

// WRONG: Don't query members in a loop - performance killer
// var gr = new GlideRecord('live_group_profile');
// while (gr.next()) {
//     var memberGr = new GlideRecord('live_group_member');
//     memberGr.addQuery('group', gr.sys_id); // N+1 query problem

// RIGHT: Use join query or GlideAggregate for membership checks
var gr = new GlideRecord('live_group_profile');
gr.addJoinQuery('live_group_member', 'sys_id', 'group')
  .addCondition('member', gs.getUserID());
gr.query(); // Single efficient query

Related Tables

sys_user task sys_user_group

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue