# 7. Processes # 7.1. User management processes ## User creation process [![user creation process.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/oU0user-creation-process.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/oU0user-creation-process.png) f an organisation requires a new user, two possible scenarios arise, either the organisation already exists in the system, or a new organisation needs to be created. ### New organisation For new organisations the request needs to be send to the Application Administrator (MyConnectivity) that is the only role that can create new organisations. The requests is then analysed and approved / rejected by the Application Administrator. If the organisation is approved, it gets inserted in the system and then the application administrators can treat the API user request as any other user request. ### New API user New users can be requested to the Application Administrator or, if the organisation already exists in the system and the organisation has an Organisation Administrator, to an Organisation Administrator. The Administrator then analyses the request and can approve or reject it. If the user is approved, it is inserted in the System and a Administrator confirms its creation to the requestor. The way the user will receive his credentials will depend on the Authentication Provider used and will not be described here. ## User deletion process Organisation Administrators as well as Application Administrators can mark users as deleted. Marking the users as deleted will make it impossible for that user to login. Furthermore the system will not allow any creation of new links to that user, effectively it is as if the user would not exist anymore. The user itself does not get deleted and any potential private data will be deleted. The goal of keeping this data is to keep a trace of which user object performed which operations in the system and to be able to identify to which organisation it belonged.

The system will automatically mark users as inactive if they are not used for a period of time defined by MyConnectivity. Inactive users will be deleted after a given time, if they are not re-activated.

## Inactive user deletion process Users can be marked as inactive, if they will not be using the system for a while (e.g. suspended account or temporary deactivation). Inactive users cannot login an cannot perform any action on the system. If an inactive user is not re-activated within a reasonable time interval X, the user will be automatically deleted. The exact value of X will be a parameter chosen by MyConnectivity, that can be adapted as needed. ## Organisation deletion process Organisation deletion follows the same principles as the user deletion process, except that the organisations can only be marked as deleted by Application Administrators. When an organisation is marked as deleted, all users linked to the organisation are also marked as deleted. Organisations must be explicitly deleted and are not automatically deleted when no users are assigned to it, this is important as an organisation can also be used in contexts others then document production (e.g. as a owners of equipments or contacts for a building) # 7.2. Create missing address process [![create missing address process.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/create-missing-address-process.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/create-missing-address-process.png)

Name	Create Missing Address Request
Purpose	Allow Editors to add missing addresses to the system, so that they are not blocked during the data ingestion processes.
Linked user stories	[4.28. Editor - Create temporary address](https://doc.rncv.lu/books/architecture-documentation/page/428-editor-create-temporary-address "4.28. Editor - Create temporary address")
APIs used	POST /addresses
Scope	This process only handles the creation of the address in a temporary state. This state will allow the Editors to enter data into the vertical cabling database for that temporary address. The process of validating and approving the temporary addresses is out of the scope of this process.
Roles	Organisation Editor, System
Input	- address (mandatory) - site structure, including site → blocks → units (optional)
Output	- temporary address - the given site structure or the default one if not structure was provided

## Detailed Process description ### Main process

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	An Editor sends a “create address request”.	Editor	- Address (mandatory) - Site structure (optional)	-
2	The system checks if the address already exists	System	- Address (mandatory) - Site structure (optional)	- yes / no	If the address does not exist: - the ingestion process continues (Step 3) If the address exists: - An error is returned (E.1. Address exists)
3	The system checks if their are high confidence matches (e.g. potential spelling mistakes in the street / locality)	System	- Address	- list of high confidence matches (if any)	If no high confidence matches: - the ingestion process continues (Step 4) If high confidence matches are found: - Matches are returned to the Editor for verification (secondary process: S.1. High confidence address verification)
4	The system creates the address in the database with a flag indicating that it is a temporary address that is not yet validated.	System	- Address (with flag validated=false)	- Newly created address
5	The system checks if a site structure was sent with the “create address request”.	System	- Create address request	- yes / no	If a site structure is provided: - the provided structure is created. If no site structure is provided: - a default structure is created.
6.a	The system creates the provided site structure	System	- Requested site structure	- Newly created site structure
6.b	The system creates the default site structure	System	-	- Newly created default site structure
7	The system returns the created address and the site structure	System	-	- Newly created address and site structure
8	The Editor gets the newly requested address	Editor	-	- Newly created address and site structure

### Secondary Processes #### S.1. High confidence address verification

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	System returns a list of high confidence address matches	System	-	- list of high confidence matches
2	Editor verifies if the address is present in the list	Editor	- list of high confidence matches	- yes / no	If address not present: - the secondary process continues (S.1. Step 3) If address present: - the ingestion process is canceled (E.2. Address exists)
3	The Editor sends again a “create address request” but this time flags it as forced (force = true)	Editor	- Address (mandatory) - Site structure (optional)	-
4	The system checks if the address already exists	System	- Address (mandatory) - Site structure (optional)	- yes / no	If the address does not exist: - the main process continues (Step 4) If the address exists: - An error is returned (E.1. Address exists)

### Error Processes #### E.1. Address exists (System error)

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	System returns an error indicating that the address already exists	System	-	Error: Address exists

#### E.2. Address exists (Editor cancel)

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	Editor finds the address in the high confidence matches returned by the system. The process is canceled.	Editor	-	-

## Additional Information ### Address matching processes Exact match (link to algorithm or process) High confidence match (link to algorithm or process) ### Default site structure [![default site structure.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/default-site-structure.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/default-site-structure.png) If no site structure is sent with the “address creation request”, a default site structure will be created composed of a site, to which one block is linked. No units are created by default, as more information is needed to create the units (floor, identification). ### Exceptions #### \[400 Bad Request\] Invalid input: If mandatory fields are missing or fields are invalid, the system returns an error message. #### \[409 Already Exists\] Address already exists If the **Editor** attempts to add an address that already exists, an error is returned. #### \[300 Similar exists\] High confidence matches If the **Editor** attempts to add an address for which the system detects high confidence matches and the force flag is set to false, the system return an error 300 and the list of high confidence matches. #### \[500 Internal Server Error\] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. # 7.3. Create missing address for existing site or block process [![create missing address for site or block.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/create-missing-address-for-site-or-block.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/create-missing-address-for-site-or-block.png)

Name	Create missing address for existing site or block process
Purpose	Allow Editors to add missing addresses for an existing site or block to the system, so that they are not blocked during the data ingestion processes.
Linked user stories	[4.29. Editor - Create an additional temporary address for an existing site](https://doc.rncv.lu/books/architecture-documentation/page/429-editor-create-an-additional-temporary-address-for-an-existing-site-canceled "4.29. Editor - Create an additional temporary address for an existing site") [4.30. Editor - Create an additional temporary address for an existing block](https://doc.rncv.lu/books/architecture-documentation/page/430-editor-create-an-additional-temporary-address-for-an-existing-block "4.30. Editor - Create an additional temporary address for an existing block")
APIs used	POST /sites/<site-id>/addresses POST /blocks/<site-id>/addresses
Scope	This process only handles the creation of the address in a temporary state and link it to an existing site or block. This state will allow the Editors to enter data into the vertical cabling database for that temporary address. The process of validating and approving the temporary addresses is out of the scope of this process.
Roles	Editor, System
Input	- site id or block id (mandatory) - address (mandatory)
Output	- temporary address linked to the given site or block - the site structure attached the address

## Detailed Process description ### Main process

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	An Editor sends a “create address request” for an existing site or block.	Editor	- Site id or Block id - Address (mandatory)	-
2	The system checks if the address already exists	System	- Site id - Address (mandatory)	- yes / no	If the address does not exist: - the ingestion process continues (Step 3) If the address exists: - An error is returned (E.1. Address exists)
3	The system checks if their are high confidence matches (e.g. potential spelling mistakes in the street / locality)	System	- Address	- list of high confidence matches (if any)	If no high confidence matches: - the ingestion process continues (Step 4) If high confidence matches are found: - Matches are returned to the Editor for verification (secondary process: S.1. High confidence address verification)
4	The system creates the address in the database with a flag indicating that it is a temporary address that is not yet validated.	System	- Address (with flag validated=false)	- Newly created address
5	The system links the address to the given site or block	System	- Create address request	- Address linked to the given site or block
6	The system returns the created address and the site structure	System	-	- Newly created address and site structure
7	The Editor gets the newly requested address	Editor	-	- Newly created address and site structure

### Secondary Processes #### S.1. High confidence address verification

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	System returns a list of high confidence address matches	System	-	- list of high confidence matches
2	Editor verifies if the address is present in the list	Editor	- list of high confidence matches	- yes / no	If address not present: - the secondary process continues (S.1. Step 3) If address present: - the ingestion process is canceled (E.2. Address exists)
3	The Editor sends again a “create address request” but this time flags it as forced (force = true)	Editor	- Address (mandatory) - Site structure (optional)	-
4	The system checks if the address already exists	System	- Address (mandatory) - Site structure (optional)	- yes / no	If the address does not exist: - the main process continues (Step 4) If the address exists: - An error is returned (E.1. Address exists)

### Error Processes #### E.1. Address exists (System error)

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	System returns an error indicating that the address already exists including the site it is attached to.	System	-	Error: Address exists

#### E.2. Address exists (Editor cancel)

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	Editor finds the address in the high confidence matches returned by the system including the site it is attached to. The process is canceled.	Editor	-	-

## Additional Information ### Address matching processes Exact match (link to algorithm or process) High confidence match (link to algorithm or process) ### Exceptions #### \[400 Bad Request\] Invalid input: If mandatory fields are missing or fields are invalid, the system returns an error message. #### \[409 Already Exists\] Address already exists If the **Editor** attempts to add an address that already exists, an error is returned. #### \[300 Similar exists\] High confidence matches If the **Editor** attempts to add an address for which the system detects high confidence matches and the force flag is set to false, the system return an error 300 and the list of high confidence matches. #### \[500 Internal Server Error\] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. # 7.4. Address ingestion via the ETL process [![address ingestion process.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/address-ingestion-process.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/address-ingestion-process.png)

The background colors of the above image are to be interpreted as: - **purple**: the core application a.k.a. backend that will be built in the context of this project - **green**: supporting systems that will be used in the context of this project - **blue**: trusted parties - **red**: external users of the system

The ETL process that is responsible for ingesting data from one or multiple trusted external Address Data Providers, is a key element of the RNCV. The ETL is responsible for: - Ingest new addresses present on the Address Data Providers. - Correct existing addresses - Validate addresses ingested by the Data producers You will find below a high level representation of the ingestion process. The exact algorithms used by the ETL process are out of the scope of this project and therefore are abstracted as a black box in the process description

The ETL algorithm is out of scope of this project

## ETL Process [![etl process.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/etl-process.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/etl-process.png)

Name	Address ingestion via the ETL process
Purpose	Ingest and validate address data to maintain the quality of the RNCV’s address database database to the highest standards
Linked user stories	[4.67. ETL - Retrieve addresses](https://doc.rncv.lu/books/architecture-documentation/page/467-etl-retrieve-addresses "4.67. ETL - Retrieve addresses") [4.68. ETL - Create and update addresses](https://doc.rncv.lu/books/architecture-documentation/page/468-etl-create-and-update-addresses "4.68. ETL - Create and update addresses")
APIs used	GET /etl/addresses POST /etl/addresses GET /etl/addresses/<address-id> PUT /etl/addresses/<address-id> PATCH /etl/addresses/<address-id>
Scope	This process handles the ingestion of addresses into the RNCV’s address database. It also handles the correction and validation of existing address data. This exact algorithm used by the ETL process is out of scope of this process.
Roles	ETL, System
Input	- Addresses from the Address Data Providers - Algorithm for the address data consolidation
Output	- Consolidated and up to date RNCV address database

## Detailed Process description ### Main process

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The ETL process is periodically triggered	ETL	-	-
2	The ETL process retrieves the data to synchronise from the Address Data Providers	ETL	-	- addresses to synchronise
3	The ETL process process one address from the addresses to synchronise (could be done in parallel)	ETL	- addresses to synchronise	- next address to synchronise
4	The ETL process extracts the address information to be stored in the RNCV address database	ETL	- address to synchronise	- address information to be ingested
5	The ETL process searches for address matches in the RNCV address database	ETL	- address information to be ingested	- address present in the RNCV address database if any
6	The ETL process checks if the address is present in the RNCV address database	ETL	- address present in the RNCV address database if any	- yes / no	If the address is present: Go to step 7 Else: Go to secondary process S.1.
7	Correct address information and set the flag “validated = true”	ETL	- RNCV address	- Corrected RNCV address with flag “validated = true”
8	System applies the address update	System	- Corrected RNCV address with flag “validated = true”	- Corrected RNCV address with flag “validated = true”
9	The ETL process checks if more addresses need to be synchronised	ETL	- addresses that still need to be synchronised	- yes / no	If there are still addresses to be synchronised: Go to step 3 Else: Go to step 10
10	The ETL process terminates successfully	ETL	-	-

### Secondary Processes #### S.1. Address does not exist in the RNCV address database

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The ETL process creates a new Address with the flag “validated = true”	ETL	- address information to be ingested	- RNCV address to be created
2	The system creates the given address	System	- RNCV address to be created	- RNCV address created	Go to Main process step 9

## Additional Information ### Error processing during the ETL process If an error occurs during the ETL process (internal error, or error while using an external API), the system should log the error and process the next address. An error triggered during the processing of one address should never interrupting the ETL process for subsequent addresses, except if it is a system wide error, that would prevent all addresses from being processed. # 7.5. Send update vertical cabling request process [![update cabling request process.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/update-cabling-request-process.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/update-cabling-request-process.png)

Name	Send update vertical cabling request process
Purpose	Allow Editors to send an update request for a vertical cabling entry between two equipments
Linked user stories	[4.46. Editor - Send an update vertical cabling request](https://doc.rncv.lu/books/architecture-documentation/page/446-editor-send-an-update-vertical-cabling-request "4.46. Editor - Send an update vertical cabling request")
APIs used	POST /physical-links
Scope	This process only handles the creation of an update request for a vertical cabling entry between two existing equipments. The process of validating and approving the entry is handled in a dedicated process.
Roles	Organisation Editor, System
Input	- source equipment (mandatory) - destination equipment or destination unit (mandatory) - link type (mandatory) - additional metadata
Output	- confirmation that the update request has been transmitted

## Detailed Process description ### Main Process

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	An Editor sends a “update vertical cabling request” for two existing equipments and a specific link type.	Editor	- source equipment (mandatory) - destination equipment or destination unit (mandatory) - cable type (mandatory) - additional metadata	-
2	The System verifies that the two equipments exist	System		- yes / no	If the equipments / unit exist: - the process continues (Step 3) If the equipments / unit do not exist: - An error is returned (E.1. Equipments not found)
3	The System verifies if the equipments / unit are geographically close enough to be connected	System	- equipments / unit addresses	- yes / no	If the equipments / unit are close enough: - the process continues (Step 4) If the equipments / unit are not close enough: - An error is returned (E.2. Equipments out of reach)
4	The System stores the connection in the database, adds the flag “approved = false” and the organisation of the Editor	System	- update vertical cabling request	- connection stored with the flag “approved = false” and linked to the Editor’s organisation
5	The System triggers the approval process for the created connection	System	- stored connection	- approval process is triggered
6	The Editor gets a confirmation that the update was successfully submitted	Editor	- submission confirmation

### Error Processes #### E.1. Equipments or unit not found

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	System returns an error indicating that one or both equipment(s) or the unit do not exist	System	-	Error: Equipments or unit do not exist

#### E.2. Equipments or unit out of reach

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	System returns an error indicating that the two equipments or uni are not geographically close enough to be connected.	System	-	Error: Equipments or unit not in connection range

## Additional Information ### Deleting a cable type in between two equipments or unit Deleting a cable type between two instances follows the same process as above. In that case the user indicates in the update request that he wants to flag the connection as “deleted = true”. ### Exceptions #### \[400 Bad Request\] Invalid input: If mandatory fields are missing or fields are invalid, the system returns an error message. This includes the case in which one or both equipment(s) do not exist. #### \[409 Conflict\] Equipments or unit out of reach If the **Editor** attempts to add connection between two equipments or unit that are geographically too far away to be connected, the system should return an error. #### \[500 Internal Server Error\] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. # 7.6. Approve update vertical cabling request [![approve vertical cabling.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/approve-vertical-cabling.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/approve-vertical-cabling.png)

Name	Approve update vertical cabling request
Purpose	Allow Approvers to validate an update request for a vertical cabling entry between two equipments
Linked user stories	[4.51. Approver - Approve or reject update vertical cabling request](https://doc.rncv.lu/books/architecture-documentation/page/451-approver-approve-or-reject-update-vertical-cabling-request "4.51. Approver - Approve or reject update vertical cabling request") [4.56. Organisation Approver - Approve or reject update vertical cabling request for organisation](https://doc.rncv.lu/books/architecture-documentation/page/456-organisation-approver-approve-or-reject-update-vertical-cabling-request-for-organisation "4.56. Organisation Approver - Approve or reject update vertical cabling request for organisation")
APIs used	PUT /physical-links/<physical-link-id>/approve PUT /physical-links/<physical-link-id>/reject PUT or PATCH /physical-links/<physical-link-id>
Scope	This process only handles the validation of an already created update vertical cabling request The process of creating the entry is handled in a dedicated process.
Roles	System, Approver / Global Approver
Input	- id of the physical link update to validate - optionally the information to amend: - source equipment (mandatory) - destination equipment or unit (mandatory) - cable type (mandatory) - additional metadata
Output	- confirmation that the update request has been approved/rejected

## Detailed Process description ### Main Process

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The System sends out notifications to the Global approvers and organisation approvers, indicating that an approval a pending.	System	- Outside trigger (e.g. Editor sent a new update request)	- notification to the Global and organisation Approvers
2	The Approver verifies if the entry is valid and up to the expected quality standards	Approver	- Update physical link request	- yes / no	If the entry is valid: - Go to step 4 Else: - Go to secondary process S.1
3	The Approver verifies if pictures linked to the entry contain any private data	Approver	- Update physical link request	- yes / no	If the entry is valid: - Go to step 4 Else: - Go to secondary process S.1
4	The Approver approves the entry	Approver	- Update physical link request	- update physical link request approval
5	The System verifies if the equipments/unit for which a physical link approval is sent exist	System	- update physical link request to approve	- yes / no	If the equipments/unit exist: - Go to step 6 Else: - Go to error E.1
6	The System verifies that the two equipments/unit are geographically close enough to be connected	System	- update physical link request to approve	- yes / no	If the equipments/unit are close enough: - Go to step 7 Else: - Go to error E.2
7	The System marks the update as approved and adds the approval date as well as the approver	System	- update physical link request to approve	- Approved update request
8	The Approver gets notified that the approval was successfully done	Approver	- update request approval confirmation	-

### Secondary Processes #### S.1. Submitted update physical link request needs adaptations

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The Approver verifies if the update physical link request is partially valid and can be corrected	Approver	- update physical link request	- yes / no	If the request can be corrected by the approver: Go to step 2 Else: Go to secondary process S.2.
2	The Approver corrects the submitted update request	Approver	- update physical link request	- corrected update physical link request	Go back to main process Step 4

#### S.1. Submitted update is rejected

Step	Description	Actor(s)	Input(s)	Output(s)
1	The Approver rejects the entry	Approver	- update physical link request	- update physical link request rejection
2	The System marks the request as rejected and adds the date as well as the approver to the rejected update request	System	- update physical link request rejection	- rejected update physical link request
3	The Approver gets a confirmation that the update request has been rejected	Approver	- update physical link request rejection confirmation

### Error Processes #### E.1. Equipments / unit not found

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	System returns an error indicating that one or both equipment(s) / unit do not exist	System	-	Error: equipments / unit do not exist

#### E.2. Equipments / unit out of reach

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	System returns an error indicating that the two equipments / unit are not geographically close enough to be connected.	System	-	Error: equipments / unit not in physical link range

## Additional Information ### Exceptions #### \[400 Bad Request\] Invalid input: If mandatory fields are missing or fields are invalid, the system returns an error message. This includes the case in which one or both equipment(s) / unit do not exist. #### \[409 Conflict\] Equipments / unit out of reach If the **Editor** attempts to add physical link between two equipments / unit that are geographically too far away to be connected, the system should return an error. #### \[500 Internal Server Error\] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. # 7.7. Approve delete site request [![approve deleted process.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/approve-deleted-process.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/approve-deleted-process.png)

Name	Approve delete site request
Purpose	Allow Approver to validate a site delete request
Linked user stories	[4.33. Editor - Delete a site](https://doc.rncv.lu/books/architecture-documentation/page/433-editor-delete-a-site "4.33. Editor - Delete a site") [4.47. Approver - Approve deleted site request](https://doc.rncv.lu/books/architecture-documentation/page/447-approver-approve-deleted-site-request "4.47. Approver - Approve deleted site request") [4.52. Organisation Approver - Approve deleted site request for organisation](https://doc.rncv.lu/books/architecture-documentation/page/452-organisation-approver-approve-deleted-site-request-for-organisation "4.52. Organisation Approver - Approve deleted site request for organisation")
APIs used	PUT /sites/<site-id>/approve PUT /sites/<site-id>/reject PUT or PATCH /sites/<site-id>
Scope	This process only handles the validation of an already created site deletion request
Roles	System, Approver / Global Approver
Input	- id of the site that is marked for deletion - optionally the information to amend
Output	- confirmation that the update request has been approved/rejected

## Detailed Process description ### Main Process

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The System sends out notifications to the Global approvers and organisation approvers, indicating that an approval a pending.	System	- Outside trigger (e.g. Editor sent a delete request)	- notification to the Global and organisation Approvers
2	The Approver verifies if the site can be deleted	Approver	- Site deletion request	- yes / no	If the site can be deleted: Go to step 3 Else: Go to secondary process S.1
3	The System marks the site with the flag “is\_deleted = true” and adds the information on the date of validation and the user that validated the request	System	- site with flag “marked\_for\_deletion = true”	- site with flag “is\_deleted = true” - approver set to the user that triggered the approval - approval date set to the current date
4	The System sets all the objects linked to the site with the flag “is\_deleted = true” (blocks, units, equipments).	System	- site	- all linked objects marked with the flag “is\_deleted = true”
5	The System creates validated update requests with the flag “is\_deleted = true” for each active physical link that are connected to at least one unit of the site.	System	- site	- new validated physical links with the flag “is\_deleted = true” for each active physical link that links at least one unit of the deleted site
6	The Approver gets a confirmation that the approval has been applied	Approver	- confirmation of the validation

### Secondary Processes #### S.1. Delete site request rejected

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The System removes the mark\_for\_deletion tag from the site entry	System	- site marked for deletion	- site with the flag “mark\_for\_deletion = false”
2	The Approver gets a confirmation that the deletion rejection has been applied	Approver	- deletion request rejection confirmation

### Exceptions #### \[400 Bad Request\] Invalid input: If mandatory fields are missing or invalid, the system returns an error message. If some addresses do not exist in the system, this is also considered as a bad request. #### \[404 Not Found\] Site not found Error returned by the system if the site is not found. #### \[409 Conflict\] Site not marked for deletion Error returned by the system if the site being validated is not marked for deletion. #### \[500 Internal Server Error\] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. # 7.8. Approve delete block request [![Approve delete block request.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/approve-delete-block-request.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/approve-delete-block-request.png)

Name	Approve delete block request
Purpose	Allow Approver to validate a block delete request
Linked user stories	[3.36. Editor - Delete a block](https://doc.rncv.lu/books/architecture-documentation/page/336-editor-delete-a-block "3.36. Editor - Delete a block") [4.48. Approver - Approve deleted block request](https://doc.rncv.lu/books/architecture-documentation/page/448-approver-approve-deleted-block-request "4.48. Approver - Approve deleted block request") [4.53. Organisation Approver - Approve deleted block request for organisation](https://doc.rncv.lu/books/architecture-documentation/page/453-organisation-approver-approve-deleted-block-request-for-organisation "4.53. Organisation Approver - Approve deleted block request for organisation")
APIs used	PUT /blocks/<block-id>/approve PUT /blocks/<block-id>/reject PUT or PATCH /blocks/<block-id>
Scope	This process only handles the validation of an already created block deletion request
Roles	System, Approver / Global Approver
Input	- id of the block that is marked for deletion - optionally the information to amend
Output	- confirmation that the update request has been approved/rejected

## Detailed Process description ### Main Process

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The System sends out notifications to the Global approvers and organisation approvers, indicating that an approval a pending.	System	- Outside trigger (e.g. Editor sent a delete request)	- notification to the Global and organisation Approvers
2	The Approver verifies if the block can be deleted	Approver	- Block deletion request	- yes / no	If the site can be deleted: Go to step 3 Else: Go to secondary process S.1
3	The System verifies if the site has other blocks than the one being deleted	System	- Block to be deleted	- yes / no	If the site has more blocks: Go to step 4 Else: Go to E.1
4	The System marks the block with the flag “is\_deleted = true” and adds the information on the date of validation and the user that validated the request	System	- block with flag “marked\_for\_deletion = true”	- block with flag “is\_deleted = true” - approver set to the user that triggered the approval - approval date set to the current date
4	The System sets all the objects linked to the block with the flag “is\_deleted = true” (units, equipments).	System	- block	- all linked objects marked with the flag “is\_deleted = true”
5	The System creates validated update requests with the flag “is\_deleted = true” for each active physical link that are connected to at least one unit of the block.	System	- block	- new validated physical links with the flag “is\_deleted = true” for each active physical link that links at least one unit of the deleted block
6	The Approver gets a confirmation that the approval has been applied	Approver	- confirmation of the validation

### Secondary Processes #### S.1. Delete block request rejected

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The System removes the mark\_for\_deletion tag from the block entry	System	- block marked for deletion	- block with the flag “mark\_for\_deletion = false”
2	The Approver gets a confirmation that the deletion rejection has been applied	Approver	- deletion request rejection confirmation

### Error Processes #### E.1. Last block can’t be deleted

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The Approver gets an error indicating that the last block of a site cannot be deleted	System	- Error: last block can’t be deleted

### Exceptions #### \[400 Bad Request\] Invalid input: If mandatory fields are missing or invalid, the system returns an error message. If some addresses do not exist in the system, this is also considered as a bad request. #### \[404 Not Found\] Block not found Error returned by the system if the block is not found. #### \[409 Conflict\] Block not marked for deletion Error returned by the system if the block being validated is not marked for deletion. #### \[500 Internal Server Error\] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. # 7.9. Approve delete unit request [![Approve delete unit request.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/approve-delete-unit-request.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/approve-delete-unit-request.png)

Name	Approve delete unit request
Purpose	Allow Approver to validate a unit delete request
Linked user stories	[4.39. Editor - Delete a unit](https://doc.rncv.lu/books/architecture-documentation/page/439-editor-delete-a-unit "4.39. Editor - Delete a unit") [4.49. Approver - Approve deleted unit request](https://doc.rncv.lu/books/architecture-documentation/page/449-approver-approve-deleted-unit-request "4.49. Approver - Approve deleted unit request") [4.54. Organisation Approver - Approve deleted unit request for organisation](https://doc.rncv.lu/books/architecture-documentation/page/454-organisation-approver-approve-deleted-unit-request-for-organisation "4.54. Organisation Approver - Approve deleted unit request for organisation")
APIs used	PUT /units/<unit-id>/approve PUT /units/<unit-id>/reject PUT or PATCH /units/<unit-id>
Scope	This process only handles the validation of an already created unit deletion request
Roles	System, Approver / Global Approver
Input	- id of the unit that is marked for deletion - optionally the information to amend
Output	- confirmation that the update request has been approved/rejected

## Detailed Process description ### Main Process

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The System sends out notifications to the Global approvers and organisation approvers, indicating that an approval a pending.	System	- Outside trigger (e.g. Editor sent a delete request)	- notification to the Global and organisation Approvers
2	The Approver verifies if the unit can be deleted	Approver	- unit deletion request	- yes / no	If the unit can be deleted: Go to step 3 Else: Go to secondary process S.1
3	The System marks the unit with the flag “is\_deleted = true” and adds the information on the date of validation and the user that validated the request	System	- unit with flag “marked\_for\_deletion = true”	- unit with flag “is\_deleted = true” - approver set to the user that triggered the approval - approval date set to the current date
4	The System sets all the quipments linked to the site with the flag “is\_deleted = true”.	System	- unit	- all linked equipments marked with the flag “is\_deleted = true”
5	The System creates validated update requests with the flag “is\_deleted = true” for each active physical link that are linked to the deleted equipments	System	- unit	- new validated physical links with the flag “is\_deleted = true” for each active physical link that is linked to the deleted equipments
6	The Approver gets a confirmation that the approval has been applied	Approver	- confirmation of the validation

### Secondary Processes #### S.1. Delete unit request rejected

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The System removes the mark\_for\_deletion tag from the unit entry	System	- unit marked for deletion	- unit with the flag “mark\_for\_deletion = false”
2	The Approver gets a confirmation that the deletion rejection has been applied	Approver	- deletion request rejection confirmation

### Exceptions #### \[400 Bad Request\] Invalid input: If mandatory fields are missing or invalid, the system returns an error message. If some addresses do not exist in the system, this is also considered as a bad request. #### \[404 Not Found\] Unit not found Error returned by the system if the unit is not found. #### \[409 Conflict\] Unit not marked for deletion Error returned by the system if the unit being validated is not marked for deletion. #### \[500 Internal Server Error\] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation. # 7.10. Approve delete equipment request [![Approve delete equipment request.png](https://doc.rncv.lu/uploads/images/gallery/2025-10/scaled-1680-/approve-delete-equipment-request.png)](https://doc.rncv.lu/uploads/images/gallery/2025-10/approve-delete-equipment-request.png)

Name	Approve delete equipment request
Purpose	Allow Approver to validate an equipment delete request
Linked user stories	[4.42. Editor - Delete an equipment](https://doc.rncv.lu/books/architecture-documentation/page/442-editor-delete-an-equipment "4.42. Editor - Delete an equipment") [4.50. Approver - Approve deleted equipment request](https://doc.rncv.lu/books/architecture-documentation/page/450-approver-approve-deleted-equipment-request "4.50. Approver - Approve deleted equipment request") [4.55. Organisation Approver - Approve delete equipment request for organisation](https://doc.rncv.lu/books/architecture-documentation/page/455-organisation-approver-approve-delete-equipment-request-for-organisation "4.55. Organisation Approver - Approve delete equipment request for organisation")
APIs used	PUT /equipments/<equipment-id>/approve PUT /equipments/<equipment-id>/reject PUT or PATCH /equipments/<equipment-id>
Scope	This process only handles the validation of an already created equipment deletion request
Roles	System, Approver / Global Approver
Input	- id of the unit that is marked for deletion - optionally the information to amend
Output	- confirmation that the update request has been approved/rejected

## Detailed Process description ### Main Process

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The System sends out notifications to the Global approvers and organisation approvers, indicating that an approval a pending.	System	- Outside trigger (e.g. Editor sent a delete request)	- notification to the Global and organisation Approvers
2	The Approver verifies if the equipment can be deleted	Approver	- equipment deletion request	- yes / no	If the equipment can be deleted: Go to step 3 Else: Go to secondary process S.1
3	The System marks the equipment with the flag “is\_deleted = true” and adds the information on the date of validation and the user that validated the request	System	- equipment with flag “marked\_for\_deletion = true”	- equipment with flag “is\_deleted = true” - approver set to the user that triggered the approval - approval date set to the current date
4	The System creates validated update requests with the flag “is\_deleted = true” for each active physical link that are linked to the deleted equipments	System	- unit	- new validated physical links with the flag “is\_deleted = true” for each active physical link that is linked to the deleted equipments
5	The Approver gets a confirmation that the approval has been applied	Approver	- confirmation of the validation

### Secondary Processes #### S.1. Delete equipment request rejected

Step	Description	Actor(s)	Input(s)	Output(s)	Decision points
1	The System removes the mark\_for\_deletion tag from the equipment entry	System	- equipment marked for deletion	- equipment with the flag “mark\_for\_deletion = false”
2	The Approver gets a confirmation that the deletion rejection has been applied	Approver	- deletion request rejection confirmation

### Exceptions #### \[400 Bad Request\] Invalid input: If mandatory fields are missing or invalid, the system returns an error message. #### \[404 Not Found\] Equipment not found Error returned by the system if the given equipment does not exist. #### \[500 Internal Server Error\] System Error If the system fails to save changes due to an internal error, it displays an appropriate message and logs the error for further investigation.