CTT Link and Unlink

This page explains the actual CTT link, unlink, relink, and bulk-link flows shown in the team flowcharts.

API Endpoints

• POST /ticket/ctt/link
• POST /ticket/ctt/link/bulk
• POST /ticket/ctt/unlink
• POST /ticket/ctt/unlink/bulk
• POST /ticket/ctt/unlink-then-link

Purpose

These flows manage the relationship between a CTT and an NTT.

They do more than update one field in the database. They also:

• validate that the CTT and NTT pair is real
• prevent duplicate or invalid links
• sync the relationship to external systems
• trigger follow-up jobs and audit trails
• rollback the DB change if external sync fails

Main business idea

At business level:

• link creates a new CTT to NTT relationship
• unlink removes an existing CTT to NTT relationship
• unlink then relink safely moves a CTT from one NTT to another
• bulk link runs the same link logic over many items and returns an aggregated result

Manual link flow

The manual link flow starts from a manual link request.

Flow summary

Step	Business meaning
Load CTT by cttId	the request must point to a real CTT
CTT found?	if not, the link request fails immediately
Load NTT by nttId	the target NTT must also exist
NTT found?	if not, the link request fails immediately
CTT already linked?	duplicate links are blocked
Save CTT -> NTT link in DB	the relationship is written locally first
DB save success?	if DB write fails, the link fails
CTT source is TaaS?	decides which external system receives the link sync
Send LINK to TaaS or TMF	external system must accept the new relationship
External sync success?	if sync fails, the local DB link is rolled back
Update NTT cttCount	the target NTT count is updated
Trigger create-ctt-related-kci job	follow-up async job is triggered
Notify related work orders / TMF update list	downstream updates are triggered
Write CTT and NTT audit logs	both sides get audit history
Return linked CTT response	caller receives success response

Main failure gates

Manual link fails when:

• CTT is not found
• NTT is not found
• CTT is already linked
• DB save fails
• TaaS or TMF sync fails

Important behavior

If external sync fails:

• the DB link is rolled back
• the request fails as external sync failed

This means a DB success alone is not enough for link success.

Manual unlink flow

The manual unlink flow starts from a manual unlink request.

Flow summary

Step	Business meaning
Loop each cttId	unlink can process more than one CTT item
Load CTT and verify linked to given NTT	the system checks the current pair really exists
Valid linked pair?	invalid or missing links are rejected
Clear CTT nttId and nttTicketNo in DB	the local relationship is removed
DB unlink success?	if DB update fails, unlink fails
Send UNLINK to TMF or TaaS	the external system must be updated too
External sync success?	if sync fails, the original DB link is restored
Set unlink-block cache for cttId-nttId	prevents immediate conflicting operations
Trigger update-unlinked-ctt KCI job	follow-up async work is triggered
Latest activities exist?	decides whether a follow-up activity/note is created
Create follow-up activity and note or skip	optional operational follow-up
Update NTT cttCount	count is refreshed after unlink
Write CTT audit log	unlink is recorded on CTT side
Write matching NTT audit log	unlink is recorded on NTT side
Return unlinked response	caller receives success response

Main failure gates

Manual unlink fails when:

• the current CTT and NTT pair is invalid or missing
• DB unlink fails
• external unlink sync fails

Important behavior

If external unlink sync fails:

• the original link is rolled back
• the request fails as external unlink failed

So unlink also depends on both local DB success and external sync success.

Unlink then relink flow

This flow starts from an unlink-then-link request and is used when a CTT must move from one NTT to another.

Flow summary

Step	Business meaning
Resolve target NTT by ticketNo	the new target NTT must exist first
Target NTT found?	if not, the whole request fails
Initialize result counters	success, failed, and skipped results are tracked
Loop each cttId	each CTT is processed one by one
Load CTT	each requested CTT must exist
CTT found?	missing CTT is marked failed
Read current linked NTT	current relationship is inspected
Already linked to target NTT?	if yes, item is counted as success and skipped
Linked to another NTT?	if yes, unlink current NTT first
Run unlink flow from current NTT	safe cleanup before moving to target
Run link flow to target NTT	create the new relationship
Relink success?	success increments success counter; failure captures error
More items?	continue until all requested CTT items are processed
Any success?	if none succeeded, fail whole request; otherwise return mixed result summary

Key behavior

This flow treats each item independently, but the final response is aggregated.

It can return:

• successful moves
• failed items with errors
• items skipped because they were already on the target NTT
• items skipped because unlink was not needed

Important business rule

If a CTT is already linked to the target NTT:

• it is counted as success
• it is skipped rather than relinked again

Bulk link flow

Bulk link is a wrapper flow around the manual link logic.

Flow summary

Step	Business meaning
Bulk link request	a batch of CTT-NTT pairs is submitted
Initialize result counters	batch result tracking starts
Loop each CTT-NTT pair	each pair is handled separately
Build per-item remark	remarks are prepared for reporting
Run manual link flow for item	the normal single-item link logic is reused
Item link success?	update success or failure counters
More items?	continue until batch is complete
Any success?	if none succeed, fail the whole batch; otherwise return aggregated results

Key behavior

Bulk link does not use a simpler path.

It reuses the manual link flow for each item, which means batch results still depend on:

• CTT existence
• NTT existence
• duplicate link check
• DB save success
• external sync success

Decision matrix

Action	When to use it	Main success condition	Main failure risk
Manual link	create a new CTT-to-NTT relationship	DB save and external sync both succeed	duplicate link or external sync failure
Manual unlink	remove an existing relationship	valid pair, DB unlink, and external sync all succeed	invalid pair or rollback after external failure
Unlink then relink	move a CTT to another NTT	target exists and per-item move succeeds	missing target, item failure, or relink error
Bulk link	link many items in one request	at least some items succeed	every item fails, causing whole request failure

What this means for developers

• do not treat link or unlink as DB-only operations
• keep rollback behavior intact when external sync fails
• keep audit logging on both CTT and NTT sides
• preserve NTT cttCount updates after successful relationship changes
• remember that bulk link depends on single-item manual link behavior
• remember that relink uses aggregated counters, not only one pass/fail result

What this means for QA and support

When checking a link or unlink issue, verify these in order:

1. did the target CTT exist
2. did the target NTT exist
3. was the pair already linked or missing
4. did the DB write succeed
5. did TaaS or TMF sync succeed
6. was rollback triggered
7. was NTT cttCount updated
8. were follow-up jobs or audit logs written

Final outcomes by flow

Flow	Success outcome	Failure outcome
Manual link	linked response returned after sync, count update, job trigger, notify, and audit	fail for not found, duplicate, DB save, or external sync
Manual unlink	unlinked response returned after sync, cache set, KCI update, count update, and audit	fail for invalid pair, DB unlink, or external unlink sync
Unlink then relink	aggregated result with success, failed, skipped-unlink, and already-on-target counts	whole request fails if nothing succeeds
Bulk link	aggregated success or mixed result	whole batch fails if no item succeeds

Related references

• CTT Overview
• CTT Flowcharts
• Manual CTT Link PDF
• Manual CTT Unlink PDF
• Unlink Then Relink PDF
• Bulk Link CTT PDF
• CTT Verification
• Ticket Service
• Queue Services

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
which actor roles may manually link or unlink	business permission clarity
when TaaS is chosen versus TMF for unlink flow	external routing clarity
whether unlink-block cache has a timeout or operational rule	helps troubleshoot repeated actions
what user-facing message should appear for each rollback case	improves support and QA clarity