One thing to note is that the work_notes
field is not actually a field on the table, the work_notes
field is of type journal_input
, which means it's really just a gateway to the actual underlying data model. "Modifying" work_notes
actually just inserts into sys_journal_field
.
sys_journal_field
is the table which stores the work notes you're looking for. Given a sys_id of an incident record, this URL will give you all journal field entries for that particular record:
/sys_journal_field_list.do?sysparm_query=name=task^element_id=<YOUR_SYS_ID>
You will notice this includes ALL journal fields (comments + work_notes + anything else), so if you just wanted work notes, you could simply add a query against element
thusly:
/sys_journal_field_list.do?sysparm_query=name=task^element=work_notes^element_id=<YOUR_SYS_ID>
What this means for you!
While you can't separate a physical row into multiple logical rows in the UI, in the case of journal fields you can join your target table against the sys_journal_field
table using a Database View. This deviates from your goal in that you wouldn't get a single row for all work notes, but rather an additional row for each matched work note.
Given an incident INC123 with 3 work notes, your report against the Database View would look kind of like this:
- Row 1: INT123 | markmilly | This is a test incident |
- Row 2: INT123 | | | Work note #1
- Row 3: INT123 | | | Work note #2
- Row 4: INT123 | | | Work note #3