IP 302 and IP 303 Workflow and Functionality

General Idea: An applicant requests technical advice related to infrastructure implementation from the infrastructure department, ensuring adherence to standards and regulations.
Initiation: The request can originate from a parent service (e.g., urban planning, transportation), a citizen requiring permits or approvals, or an employee seeking guidance on a specific infrastructure project.
Routing: The request is sent to a specific unit within the department based on the detailed classification selected by the initiator, ensuring precise assignment.
Process: The request goes to a unit employee, then a unit head. However, based on classification complexity, it may go directly to the division employee for streamlined handling.
Unit Involvement: The competent employee may send the request to one or more units (e.g., units y and z simultaneously) for collaborative input.
Parallel Processing: Two instances are created for multiple units, allowing simultaneous handling. The competent employee receives responses from all units before proceeding to consolidate feedback.
Division Head: The division head can send requests to employees under the division in parallel, speeding up the review process. Responses are always directed to the division head for centralized oversight.
Department Head: The department head can also send requests; however, responses are still directed to the division head, ensuring a structured communication flow.
Citizen/Employee Requests: Requests can be initiated by a parent service or a citizen needing infrastructure-related approvals. Employees can also initiate requests based on specific classifications for internal projects.

Employee Roles and Unit Classifications

Scenario: Department X (roads), Y (telecom), and Z (urban planning) are involved in implementation of a multi-faceted infrastructure project.
Instances: Two instances are created (implementation- Group X and implementation-Group Z) to manage parallel workflows.
Classifications: There are three classifications (1, 2, and 3) corresponding to coordination, roads, and urban planning (UP) units, each with distinct technical requirements.
Classification 1 (Coordination Unit): If the applicant selects the first classification, the request goes to the coordination unit for initial assessment and distribution.
- The competent employee belongs to the coordination unit, and the unit list excludes the coordination unit itself to avoid circular routing.

Unit Selection: The employee in the coordination unit can select multiple units (e.g., roads and telecom units) based on the project's needs.
Workflow: The request branches to the selected units (telecom and roads) in parallel, streamlining the process. It then returns to the coordination unit after all responses are gathered.
Unit-Specific Workflow: For telecom and roads units, the workflow involves an employee, a unit head, and the division head, ensuring thorough review at each level.
Parallel Instances: Multiple instances (2, 3, or 4) are created based on the number of selected units. These are configured as a multi-instance process to handle concurrent tasks.
Inter-Unit Task: If the employee needs input from another unit (e.g., roads unit), it must wait for the completion of all other parallel instances (e.g., telecom), ensuring holistic input.

Unit Employee Options and Restrictions

Scenario: A road employee sends the task to the road division, while the telecom employee completes their work, illustrating different task completion times.
Telecom Employee: Must send the request to their unit head for approval before returning it, with options to resync or request clarifications, ensuring all aspects are addressed.
Unit Ownership: The unit owning the classification has full control: they can send it to any unit, reject it, return it to the employee for edits, and more.
Clarification Requests: Other units receiving the request for clarification have limited options to maintain workflow integrity.
Limited Options: The employee can only send it to the unit head, and the unit head can only send it back or return it to the originating unit, preventing process deviations.
Conditional Results: Outcomes are conditional based on the specific details and requirements of each case.
Dynamic Implementation: The process is designed for dynamic implementation to adapt to changing needs.

Department Head Actions and Inquiry Routing

Department Head Actions: The department head can approve the project or send inquiries to other departments for additional input.
Send to Other Department: The employee can send the request to any department within the ministry via a human task for inter-departmental collaboration which streamlines the review.
Process: The department head selects the department, and the request is routed accordingly to gather necessary information.
Approval: Approving the project completes the reusable process, leading to the main process, and signifies project clearance.
Return Requests: An employee can return the request, especially if submitted by an applicant, to request additional information or corrections.
Initiator-Specific Returns: Requests initiated by an employee cannot be returned to anyone. The return option depends on who initiated the request (citizen, parent, or employee) to ensure proper handling.
Internal Portal: Requests can be initiated from an internal portal for streamlined processing.
Initiator Employee: For requests initiated by an employee, there is no return button at the employee level; the return option is managed at a higher level.
Department Head Routing: The department head returns the request to the division head, not directly to the employee, to maintain workflow management.
Department Head Options: Include approving and sending inquiries, but not returning the request directly, ensuring structured management.

Wireframes and UI Components

Copy-Paste: The workflow is the same for IP 303, ensuring consistency across similar processes.
Submit Screen: When a citizen submits the request, they specify the classification (main and sub) and provide additional information related to the submission.
Conditional Information: Additional information may be required based on classifications, such as providing data to other entities, ensuring comprehensive data collection.
Geotechnical Information: If providing geotechnical data is selected, additional fields are displayed and required, ensuring critical details are captured.
Dynamic Fields: Beneficiary information requests are dynamic, adapting to the specific project requirements.
Project Details: If a project exists, the project tab is visible, allowing selection of government entities or indicating the project owner is the same as the beneficiary.
No Project: If no project exists, the project tab is hidden to streamline the user experience.
Location Details: Location details are based on location identification (specific location or PIN), ensuring location accuracy.
Attachment Details: Attachment requirements are detailed in the wireframe and BRD, ensuring proper documentation.
Request Submission: The request is sent to the specific employee after submission for review and processing.

Employee and Unit Head Actions

Objections: Selecting or adding objection details is mandatory only when approving or rejecting, ensuring that justifications are provided for decisions.
Competent Units: The employee specifies units (2, 3, or all) to send the request to in parallel, facilitating simultaneous reviews.
Service Unit Screen: A special screen exists for service unit employees (service coordination unit) to streamline their tasks.
Unit Head Approval: The unit head can return it to the competent employee or approve the statement, maintaining oversight.
Competent Unit Employee (Return): Has options to approve, reject, or return the request to the applicant based on the review for greater efficiency.
Competent Unit Employee (See All): The employee can see all tabs and send it to other competent units or a specific division or reject the request for greater support.

Division and Department Head Actions

Division Head: The division head can send to other units or forward for inquiry to the department head, reject, or send to NetHunt for additional analysis.
Department Head: The department head reviews details, approves the statement, returns it to the division head, or sends it to other departments within the municipality (selecting only one department) for a systematic approach.
Inquiries: The Department head can send for inquiries to investigate/gather info.
Employee Lists: Two different lists are used: one for the division head inquiry and another for the department head, reflecting different privilege levels to maintain security.
Different Lists: The Division head can only send to employees under the division, while the department head can send to anyone under the department for optimized assistance.

Review and Completion Stages

Ministry Department Screens: Specific screens are used for the ministry department to facilitate their actions.
Employee Clarification: A specific screen is used for the employee to provide clarification, ensuring effective communication.
Final Result: When the service request (SR) is completed and approved, the approval screen is displayed for documentation.
Objection Status: It's an independent switch. There are two variants: objection, no objection, aiding in future actions.
Data Source: The Competent Unit employee uploads the attachment and selects whether there is an objection or not during review to streamline the process.

Business and Workflow Implications

Objection Impact: The objection status does not have an impact on the business flow but is recorded as business data for insights.
Reporting: Used for reports to monitor and optimize outcomes.
Report Generation: Data captured in the SR is used to generate approval certificates and other reports to validate actions.
Infra Facilities: Includes pipes, cables, and telecom towers for more precise requests.
Technical Reports for Infra Facilities: Include details related to infrastructure facilities to better handle requests.
IP 303: The workflow and screens are the same to ensure the process are easy to use.
Output: The output will be some report to validate projects or something for quality control.
Difference: