2.6 KiB
workload-actions Specification
Purpose
Identify workload actions owned by the signed-in user and allow eligible users to create actions for opportunity products.
Requirements
Requirement: Action enrichment respects prerequisite data
Workload Action enrichment SHALL use distinct product revenue identifiers after the product cycle and successful or reused CRM SR loading. Unavailable SR data SHALL leave action state unknown rather than treating it as an empty result.
Scenario: SR prerequisite fails
- WHEN CRM SR loading fails for a completed product cycle
- THEN action enrichment is blocked and its badges do not assert that no actions exist
Requirement: Ownership determines the action badge
The action badge SHALL aggregate returned actions for the opportunity products and mark a match when an action owner equals the general Token Relay principal. Missing principal or failed lookups SHALL not count as confirmed nonmatches.
Scenario: Actions exist for other owners
- WHEN returned actions have no owner matching the known principal
- THEN the badge indicates no matching ownership while its tooltip retains the returned actions
Requirement: Read attempts are bounded and partial coverage is disclosed
Each action lookup SHALL make at most five total attempts and stop on success or session supersession. The current lookup SHALL expose hasNext as additional unqueried actions rather than implying that all pages were loaded.
Scenario: More action pages exist
- WHEN a successful action response sets
hasNext=true - THEN the tooltip states that additional actions exist and pagination is not enabled
Requirement: Action forms use validated lookup selections
The Action form SHALL load team members and lookup values with the workload credential, support searchable selections, and submit selected codes rather than arbitrary typed search text. Required inputs and the date range SHALL be validated before Save.
Scenario: Search text is not an option
- WHEN the user types a value without selecting a valid lookup result
- THEN the text is not submitted as a valid option value
Requirement: Action creation is explicit and preserves failure state
Saving a valid action SHALL send current-user attribution, UTC dates and a notes array, lock duplicate submission while pending and show a result toast. A failed create SHALL retain the form without automatically retrying the POST.
Scenario: Create fails
- WHEN the server rejects an action creation
- THEN the form remains available with the entered data and no automatic duplicate POST is issued