Custom Journal Field Entries Display Under "Additional Comments" Label in Activity StreamIssue On a custom scoped application table that extends Task — or any table in the task hierarchy such as Case, Incident, Problem, or Change Task — journal entries written to a custom journal-type field do not appear in the Activity stream under that field's configured dictionary label. Instead, they render under the "Additional comments" label, which is the standard display label for the built-in comments field. This behavior is consistent across both the classic Platform UI (UI16 "Manage Activity Filter" slushbucket) and the modern renderers used in Agent Workspace, Service Portal, and mobile. It affects existing entries as well as new ones. Release All Cause The Activity stream determines which fields to recognize and display through a per-table system property: glide.ui.<table>_activity.fields (type: string, value: comma-separated field list). Both the classic and modern renderer stacks apply identical lookup and fallback logic: If a glide.ui.<table>_activity.fields property exists for the table, that exact field list is used.If no such property exists, and the table's absolute base table is task — which applies to any table that descends from task, at any depth, including indirect descendants through Case, Incident, or custom intermediate tables — the platform falls back to a hardcoded constant: assigned_to,cmdb_ci,state,impact,priority,opened_by,work_notes,comments,*Attachments*. This default constant includes only the two standard journal fields: work_notes and comments. Any custom journal-type field added to the table is absent from this default set. When an Activity stream entry is rendered and its source field name is not found in the recognized set, it is routed to a generic fallback bucket that surfaces under the comments field label ("Additional comments"). The rendering occurs at query time, not at write time. The underlying journal record in sys_journal_field is written correctly with the custom field name — the display issue is purely a property-driven label resolution problem, not a data loss issue. A separate, related property — glide.ui.<table>_activity.primary_fields — controls which journal fields are pinned at the top of the Activity stream (defaults to comments,work_notes if unset). This property governs display ordering and pinning only, and does not affect field recognition or label assignment. Resolution Create a system property for the affected table with the following details: Name: glide.ui.<table>_activity.fields, where <table> is the exact name of the table (for example, glide.ui.x_myapp_custom_case_activity.fields)Type: stringValue: a comma-separated list of every field that should appear in that table's Activity stream The value must include both the standard fields (if they should remain visible) and every custom journal field defined on the table. Example: assigned_to,state,priority,work_notes,comments,<custom_field_1>,<custom_field_2>,*Attachments* Replace <custom_field_1> and <custom_field_2> with the actual field names as they appear in the table's dictionary. This configuration applies at any depth in the task hierarchy. A table that extends Case, which itself extends Task, requires its own glide.ui.<table>_activity.fields property; there is no automatic inheritance of a parent table's property. To navigate to system properties: in the application navigator, search for sys_properties.list, then create a new record with the property name, type string, and the comma-separated field list as the value.