CTT Status Rules

This page explains the actual CTT status-update flow shown in the team flowcharts.

API Endpoints

• PUT /ticket/ctt/activity-status/update/:activityId
• POST /ticket/ctt/bulk-update-ctt-activity-status
• POST /ticket/ctt/bulk-resolve-by-ticket-id

Purpose

CTT status updates are not a free-form state change.

The current flowchart shows a controlled path focused on Resolved handling, with validation around:

• whether the latest CTT activity exists
• whether the CTT is already closed or cancelled
• whether the requested status is actually Resolved
• whether the resolved status must be synced to TaaS or TMF
• whether note and post-logic handling should run after the update

Main business idea

At business level, this flow means:

• not every requested status change is allowed
• already closed or cancelled CTTs cannot be updated through this path
• this path is mainly for moving a CTT into Resolved
• routing to TaaS or TMF depends on the CTT number pattern, not just a generic source label

Main status update flow

The flow starts from a status update request.

Flow summary

Step	Business meaning
Load latest CTT activity by activityId + cttId	the system must find the current activity context first
CTT activity found?	if not, the update fails immediately
Bind audit to CTT	audit tracking is attached before the state change continues
CTT already Closed or Cancel?	closed or cancelled items are blocked from update
Resolve requested status LOV	the system resolves the requested status value
Requested status = Resolved?	this flow only allows the resolved path
Build new resolved activity snapshot	the new resolved activity payload is created
Apply cause code, disposition, resolution code, delay reason	resolution metadata is attached
Validate resolution codes if needed	the request is checked for required resolution information
CTT number contains TaaS?	decides external routing target
Send resolved status to TaaS or TMF	external status sync is performed
Save resolved activity	local resolved activity is stored
Run resolved post-logic	follow-up internal logic runs
Remark provided?	optional note handling is evaluated
Create activity note or skip note	note behavior depends on whether a remark exists
Audit success and return updated activity	final updated response is returned

Main failure gates

This flow fails when:

• the latest CTT activity cannot be found
• the CTT is already Closed or Cancel
• the requested status is not Resolved

Important behavior

The flowchart makes one especially important rule clear:

• only Resolved is allowed in this update path

So this is not a generic all-status update endpoint, even if the name sounds broad.

Rule summary

Rule	Meaning
Latest activity must exist	update needs a valid current state snapshot
Closed or cancelled CTT cannot continue	terminal states are blocked
Requested status must equal Resolved	other requested statuses are rejected
Resolution metadata may be required	cause or resolution fields are part of the resolved path
CTT number pattern decides external route	TaaS in the CTT number routes to TaaS, otherwise TMF path is used
Remark is optional	note creation depends on whether a remark was provided

TaaS-specific resolved path

The Resolved CTT TaaS flowchart gives a focused view of the TaaS branch.

TaaS resolved flow summary

Step	Business meaning
Resolve CTT request	resolved flow begins
Load latest CTT activity	current state is loaded
CTT number contains TaaS?	if no, use TMF resolved flow instead
Build resolved CTT activity	local resolved structure is created
Set activity type to UCC Verification	the resolved activity type is explicitly set
Send resolved status to TaaS via updateCttStatusToTaaS(...)	external TaaS sync is performed
Save or update local resolved activity	local state is updated
Run resolved post-logic	follow-up internal logic runs
Optional note sync to TaaS	note synchronization may happen after resolve

Important TaaS rule

For TaaS-style CTT numbers:

• the resolved path is specialized
• the activity type becomes UCC Verification
• note sync to TaaS can happen after the main status update

Bulk status helper flow

The Bulk Status Helper flowchart shows how batch status processing works.

Flow summary

Step	Business meaning
Bulk status helper request	batch status operation begins
Receive list of CTT items	multiple CTT items are supplied
Loop each CTT item	each item is handled one by one
Load CTT and latest activity	each item must have valid context
CTT/activity valid?	invalid items are failed or skipped
Apply per-item resolve or update logic	normal status logic is run for each item
Needs external sync?	some items need downstream sync and some remain local-only
CTT number contains TaaS?	if external sync is needed, choose TaaS vs TMF path
Send status update to TaaS or TMF	external sync occurs when required
Keep local-only result	local result is preserved when no sync is needed
Save or update local CTT activity result	local activity state is stored
Run post-resolve logic, notes, audit	per-item completion logic runs
Mark item failed or skip	invalid items are tracked without breaking the whole loop
More items?	continue until batch is done
Finish batch processing	batch run ends

What this means

Bulk status processing:

• loops item by item
• reuses per-item status logic
• can mix external-sync and local-only results
• can mark items failed or skipped without stopping the whole batch immediately

Decision matrix

Situation	Allowed outcome	Blocked outcome
latest activity exists and requested status is Resolved	continue resolved flow	fail if other required validation fails
CTT already Closed or Cancel	none	status update blocked
requested status is not Resolved	none in this path	fail with only-resolved rule
CTT number contains TaaS	sync resolved status to TaaS	do not use TMF resolved branch
CTT number does not contain TaaS	use TMF resolved path	do not use TaaS resolved branch

What this means for developers

• do not treat this flow as a general-purpose status transition handler
• preserve the guard that blocks already closed or cancelled CTTs
• preserve the rule that this path only allows Resolved
• keep routing logic based on CTT number pattern
• keep resolution metadata handling intact
• keep audit, post-logic, and optional note creation after successful resolve
• remember that bulk status helper is a wrapper around per-item logic, not a separate business rule set

What this means for QA and support

When checking a status-update issue, verify these in order:

1. was the latest CTT activity found
2. was the CTT already closed or cancelled
3. was the requested status actually Resolved
4. were cause code, disposition, resolution code, and delay reason supplied if needed
5. did the route go to TaaS or TMF correctly
6. was the resolved activity saved locally
7. did post-logic run
8. if a remark was given, was a note created

Final outcomes

Scenario	Result
activity not found	fail: CTT activity not found
CTT already closed or cancelled	fail: status cannot update
requested status not resolved	fail: only resolved allowed
resolved request succeeds	save resolved activity, run post-logic, audit success, return updated activity
remark exists	create activity note before success return
remark missing	skip note and still return success

Related references

• CTT Overview
• CTT Flowcharts
• Update Status PDF
• Bulk Status Helper PDF
• Resolved CTT TaaS PDF
• CTT Verification
• CTT Link and Unlink
• Ticket Service

Still worth confirming with the team

The flowcharts are clear on control flow, but these details are still worth confirming in plain language:

Question	Why it matters
whether there are other status-update paths outside this resolved-only flow	prevents over-documenting this one path as universal
which resolution codes are mandatory versus optional	onboarding and QA clarity
what exact post-logic runs after resolve	downstream behavior clarity
whether bulk helper returns mixed success or only completion state to the UI	support and frontend clarity