Collaboration

The most likely reason for duplicate cards on Miguel's Data-Driven Visual Task Board is that team members manually added problem records that were already automatically populated through the board's filter conditions.

In ServiceNow Visual Task Boards (VTBs), there are two primary ways records can appear on a board:
1. Through filter conditions that automatically populate matching records
2. Through manual addition by users who drag records onto the board

When a Data-Driven VTB is configured with filter conditions, it automatically displays all records that match those criteria. If a team member then manually adds the same record to the board (perhaps not realizing it's already there), this creates a duplicate card. This is a common issue when teams use mixed methods of populating their boards.

The other explanations are incorrect:

• The suggestion that records display in multiple lanes when their priority field contains more than one value is not valid because the Priority field in ServiceNow is a single-select choice field, not a multi-select field. A record can only have one priority value at a time, so it cannot legitimately appear in multiple priority-based lanes.

• The idea that the refresh interval creates new card instances is incorrect. The refresh function in VTBs updates the display of existing cards with current data; it does not duplicate cards. The system tracks records by their unique sys_id.

• The concept of filter conditions overlapping with assignment rules to generate additional card entries is not how ServiceNow works. Assignment rules affect record field values (like assigning records to users or groups), but they do not create duplicate visual representations on task boards.

The correct answer relates to the notification condition evaluating before the role membership cache refreshes, causing stale recipient data to be used during notification generation.

In ServiceNow, role memberships and user data are often cached for performance optimization. When a notification is triggered, the system needs to determine recipients, and if the script queries role membership data, it may retrieve information from a cache that hasn't yet been updated with the latest role assignment changes. This explains the intermittent nature of the issue - sometimes the cache is current, and sometimes it's stale.

The key clues in the scenario are:
1. The notification logs show the correct recipient at generation time, but delivery goes to the wrong person occasionally
2. User records show current role assignments are accurate
3. The issue is intermittent, not consistent

This points to a caching issue where the role membership cache hasn't refreshed yet when the notification recipient resolution occurs.

The other answers are incorrect for these reasons:

• The answer about querying historical audit data is incorrect because the notification script is described as querying the sys_user_has_role table directly, not audit tables. If it were querying audit data, the issue would be consistent, not intermittent.

• The answer about workflow triggering before asynchronous role synchronization completes is less accurate because the scenario states that User records already show correct role assignments. If synchronization hadn't completed, the User records themselves would show outdated information.

• The answer about notification weight configuration is incorrect because notification weights determine which notification fires when multiple notifications match the same event - they don't affect recipient resolution within a single notification rule. Additionally, the scenario describes a single notification with a script-based recipient determination, not competing notifications.

The most appropriate action is to contact the technician's manager to discuss reassigning resources or adjusting priorities, document the current status in work notes, and provide the Problem Manager with a realistic updated timeline based on resource availability.

This is the correct approach because:

1. Proper escalation path: Sandra is an administrator, not the technician's manager. The appropriate first step is to work through the management chain rather than making unilateral decisions about resource allocation.

2. Collaborative problem-solving: The manager already confirmed the technician has been working on other high-priority incidents. This suggests a resource/priority conflict that needs management discussion, not just reassignment.

3. Documentation best practice: Adding work notes to document the current situation maintains an audit trail and keeps all stakeholders informed.

4. Stakeholder communication: Providing the Problem Manager with a realistic timeline addresses the immediate need for information from regional directors while the resource situation is being resolved.

5. Considers the bigger picture: This approach allows for a decision that weighs the priority of this task against other high-priority incidents the technician is handling.

The option to simply reassign the task to another technician bypasses proper management coordination and doesn't account for whether other technicians have capacity or the right skills.

Changing the state to 'On Hold' doesn't actively resolve the situation - it just delays it further while 23 stores and two dependent tasks continue waiting. Creating another follow-up task adds complexity without solving the core issue.

Escalating directly to the IT Director is premature and skips the normal chain of command. The technician's manager should be the first point of contact before escalating higher, and requesting additional staffing resources is a significant decision that shouldn't be the first response to a single delayed task.