RE_Documents/streamlined_approvals.md

RE Workflow Management – Not Templatized
System Requirements Specifications
13 - Oct- 2025
Version 1. 0
Contents
1 System Overview & Problem Statement
2 Use case examples
3 Intended Audience
4 HiFi Wireframe,Goals and Expected Outcomes
5 Definitions and Acronyms
6 Flow of Application
6.1 High-Level Flow
7 System Features & Requirements
7.1 SSO Login
7.2 Dashboard
7.3 Side Navigation Menu
7.4 Create New Request – Template Selection
7.5 Create New Request – Basic Information
7.6 Create New Request – Approval Workflow
7.7 Create New Request – Participants & Access
7.8 Create New Request – Documents & Attachments
7.9 Create New Request – Review & Submit
7.10 Notifications
7.11 My Requests.............................................................................................................
7.12 Request Detail View
7.13 Request Detail view - Workflow
7.14 Request Detail view - Document
7.15 Request Detail view – Activity
7.16 Add Work Note
7.17 Add Approver & Spectator
7.18 Approve / Reject Request (Popup Window)
7.19 Closure Remark
8 Client Feedback Log (Post-Review Updates)
9 Non-Functional Requirements
10 Technology Matrix
11 Infra requirements & System Hygiene
12 Not in scope
1 System Overview & Problem Statement
The Workflow Management System – Non-Templatized is a strategic digital initiative aimed at
bringing structure, traceability, and efficiency to approval-based processes within Royal Enfield
(RE).

Currently, most approvals and related communications are handled through emails , which often
results in:

Unstructured and fragmented approval chains
Loss of critical information due to scattered email threads
Lack of visibility on approval status and ownership
No defined Turnaround Time (TAT) , leading to delays and open-ended tasks
These challenges collectively reduce process transparency , accountability , and decision
efficiency across teams.

The proposed Workflow Management System – Non-Templatized will address these issues by
providing a centralized, intuitive platform where:

Users can create requests ,
Define custom approval hierarchies ,
Set and monitor TATs , and
Track real-time progress and final outcomes.
All workflows will be captured, organized, and closed within a single system of record —
ensuring clarity, control, and compliance throughout the process.

A thoughtfully designed User Interface (UI) will further enhance usability, adoption, and
productivity , ensuring smooth navigation and a clean experience across departments.

2 Use case examples
The following are some illustrative use cases for the Workflow Management System – Non-
Templatized. These examples represent common approval scenarios within the organization,
though additional use cases may be added over time as business needs evolve:

Approval for a new office location – involving multiple stakeholders such as facilities,
finance, and leadership teams.
Approval of unbudgeted incentives – requiring justification and review from HR and
finance departments.
Sponsorship or participation in an event – covering approvals from marketing, branding,
and finance.
Purchase of material from a new vendor – requiring validation, procurement, and
financial approvals.
These examples demonstrate the system’s flexibility to handle a wide range of approval
workflows across departments.

3 Intended Audience
The Workflow Management System – Non-Templatized will be accessible to all Royal Enfield
(RE) employees who have valid SSO (Single Sign-On) credentials.

Initially, the system will be introduced in a pilot environment for selected users and
departments. Based on feedback and performance, it will later be rolled out organization-wide.

The system will involve the following user roles :

Initiator – The user who creates and submits a workflow request.
Participants – Individuals involved in the workflow at different stages or approval levels.
Final Approver – The ultimate authority responsible for approving or rejecting the
workflow request.
Consultation – A user or subject matter expert whom the Final Approver may consult
before making a final decision.
Spectators – Users who are invited to view the workflow for information or transparency
purposes, similar to how individuals are copied (CC’d) on email communications.
This defined role structure ensures clarity, accountability, and collaboration throughout the
workflow lifecycle.

4 HiFi Wireframe,Goals and Expected Outcomes
Hi-Fi Wireframe: https://sway-dense-03017508.figma.site

The Workflow Management System – Non-Templatized is designed with a user-centric
approach, supported by a high-fidelity (Hi-Fi) wireframe that visually represents the layout,
navigation flow, and user interactions.

Through the implementation of this system, Royal Enfield (RE) aims to achieve the
following measurable goals :

Centralization: Consolidate all approval workflows and related communications within a
single unified platform.
Transparency: Provide real-time visibility into each workflow’s stage, status, and assigned
approvers.
Accountability: Define clear ownership at every stage and maintain a complete audit trail
of all user actions.
Efficiency: Reduce approval cycle times by implementing TAT-based
tracking , automated reminders , and smart notifications.
Traceability: Maintain structured and retrievable records of all approvals to support easy
reference, audit, and reporting.
Scalability: Enable flexible configuration of non-templatized workflows that can adapt to
various departmental and business needs.
User Experience: Deliver a clean, intuitive, and responsive interface that enhances
usability and encourages regular adoption.
5 Definitions and Acronyms
Term Definition
Workflow A sequence of tasks, approvals, or activities linked to a business process.
Non-
Templatized
A flexible structure where each workflow can be created dynamically without a fixed
format.
Admin System user with full privileges.
6 Flow of Application
This section describes the end-to-end flow of the Workflow Management – Non-Templatized
application. It outlines how users interact with the system, how approvals move through
different stages, and how data transitions between modules until final closure.

6.1 High-Level Flow
Login (SSO Integration)
o Users access the system via the RE SSO Bridge using their organizational
credentials.
o Upon successful authentication, users are redirected to the Dashboard.
Dashboard & Navigation
o The Dashboard provides a summary of pending, approved, and rejected requests.
o The left Side Menu gives access to My Requests , Open Requests , Closed Requests ,
and Raise New Request.
Creating a New Request
o User clicks “Raise New Request” and chooses between:
▪ Custom Request – Create a flexible, non-templatized workflow.
▪ Existing Template – (Future scope) Use a predefined structure.
o The user proceeds through a 6 - step wizard :
▪ Template Selection
▪ Basic Information
▪ Approval Workflow
▪ Participants & Access
▪ Documents & Attachments
▪ Review & Submit
Defining Approval Workflow
o The user configures approval levels dynamically , assigning approvers via @
tagging.
o Each approver level has a defined TAT (in hours or days).
o System calculates the total TAT by summing all levels.
o TAT starts only when a request reaches that approver’s level.
Adding Participants
o User can add Spectators (view-only participants) who can comment but not
approve.
o Spectators receive notifications and see the request in read-only mode.
Uploading Documents
o User attaches supporting files (PDF, Word, Excel, PPT, or images) or links Google
Docs/Sheets.
o PDFs and images are previewable , while other formats can be downloaded.
Submitting the Request
o The user reviews all information in the Review & Submit step.
o Once submitted, the request enters the Approval Workflow and notifies the first
approver.
Approval Process
o Approvers receive a notification and can:
▪ Approve Request – Moves to the next level or closes if final approver.
▪ Reject Request – Sends remarks to the initiator and marks as closed.
o Each action requires comments and remarks (mandatory).
o TAT tracking is visible with color-coded status (Green = Within TAT, Yellow =
Approaching Deadline, Red = Breached).
o Auto-reminders are sent at configured thresholds (e.g., 80% TAT usage).
Work Notes & Collaboration
o Participants communicate via the Work Notes (Chat View).
o Supports @mentions, file sharing, and reactions.
o All discussions are stored chronologically and linked to the request.
Activity Tracking
o Every event — creation, comment, document upload, approval, rejection, or TAT
alert — is captured in the Activity Tab with timestamps.
Request Closure & Conclusion
o After final approval, the request returns to the Initiator with AI-generated
conclusion remarks.
o The initiator reviews, optionally edits, and marks the request as closed.
o The Conclusion Remark summarizing the workflow becomes part of the final
record and appears under:
▪ My Requests (Approved)
▪ Open Requests
▪ Closed Requests
Post-Closure Access & Sharing
o Closed requests remain accessible to all participants and spectators.
o Requests can be shared internally via Add Spectator ;
download permissions apply only to Work Note attachments.
o All actions and comments remain viewable for audit purposes.
7 System Features & Requirements
Here, we describe the system features along with their respective Width and Depth to provide
complete visibility of each requirement.

The Width defines the functional coverage of a feature — outlining what the feature does,
its boundaries, use cases, and user interactions. It answers the question: “What scenarios and
actions are covered by this feature?”

The Depth captures the operational and behavioral details — describing how the feature
behaves through its logic, workflow, system responses, and edge-case handling. It answers the
question: “How does the system execute and respond in these scenarios?”

7.1 SSO Login
The system will integrate with the existing RE SSO Bridge to enable secure, seamless login for all
authorized Royal Enfield employees. This ensures unified authentication, eliminating the need
for separate credentials and maintaining compliance with RE’s security standards.

Width:

Integrates with the existing RE SSO Bridge for secure authentication.
Allows access only to authorized Royal Enfield employees.
Automatically retrieves user details ( name, employee ID, department ).
Depth:

Uses token-based authentication and HTTPS for secure sessions.
Handles session timeout and re-authentication per RE’s IT security policy.
Dependency

SSO implementation guide and sample users are required.
7.2 Dashboard
The Dashboard is an open element that is currently under discussion and will be finalized in later
phases. It is expected to serve as a central view for users to monitor workflow status, pending
approvals, and key metrics once its structure and content are defined.

7.3 Side Navigation Menu
The Side Menu provides users with quick and consistent navigation across the application. It
includes the following primary sections:

Dashboard: Overview of workflow activities, key metrics, and pending actions.
My Requests: Displays all workflow requests created by the logged-in user.
Open Requests: Lists all active or in-progress workflows requiring action. These may
include requests initiated by or assigned to the logged-in user.
Closed Requests: Shows all completed or approved workflows for reference. These may
include requests created by or processed by the logged-in user.
Raise New Request: Allows users to initiate and submit a new workflow request.
Width:

Offers persistent navigation to Dashboard , My Requests , Open Requests , Closed
Requests , and Raise New Request.
Ensures consistent access throughout the system.
Depth:

Implements active route highlighting and role-based visibility.
Includes search, sort, and filter capabilities.
Supports pagination and stable ID-based navigation to detail screens.
7.4 Create New Request – Template Selection
This screen appears when the user clicks “Raise New Request.” It introduces a wizard-style
navigation that guides users through the request creation process in sequential steps.

Custom Request (Non Templatized): Allows users to create a fully flexible workflow tailored to
unique business needs.

To initiate the request flow, users must select “Custom Request.” The system then progresses
step by step to capture all required details, ensuring clarity and completeness before submission.

Width:

Enables users to choose Custom Request (non-templatized)
Displays wizard navigation with progress indicator.
Depth:

In the current version, only Custom Request is enabled.
Enforces mandatory selection before proceeding.
Saves the chosen configuration as part of the workflow metadata.
Activates after completion of wizard
7.5 Create New Request – Basic Information
In this step, users outline the what, why, and how soon of their request, creating clarity for all
participants involved in the approval process.

Users are required to enter:

Request Title: A short and descriptive title that summarizes the purpose of the request
(e.g., Approval for new office location ).
Detailed Description: A comprehensive explanation outlining the need, background, and
expected outcome of the request.
Priority Level: Selection between two options —
o Express (Urgent): Includes calendar days in the TAT for faster processing.
o Standard (Default): Includes working days in the TAT for regular processing.
This step ensures that each request is well-defined, prioritized appropriately, and easily
understood by all participants in the approval flow.

Width:

Captures core request details :
o Request Title
o Detailed Description
o Priority Level – Express or Standard
Depth:

Express: Uses calendar days in TAT calculation.
Standard: Uses working days (default).
Supports rich text formatting and pasted tables for better clarity.
Support comprehensive email like formatting features , including table insertion, links,
and text formatting such as bold and italics
•
7.6 Create New Request – Approval Workflow
In this step, users define the approval hierarchy and assign approvers for each level. The number
of approvers is dynamically configurable based on the workflow’s complexity, with a maximum
of ten levels supported.

Each approver’s Turnaround Time (TAT) must be defined individually in hours or days ,
depending on the urgency and scope of the request. The system automatically calculates
the overall TAT by summing the TAT values of all approval levels.

An important behavior to note: the TAT timer for each participant starts only when the request
reaches that level. Any delay at a previous level impacts only that approver’s TAT and does not
affect subsequent ones.

Approvers can be tagged using the “@” symbol for easy identification, and each level’s
configuration is summarized in real time under the Approval Flow Summary and TAT
Summary sections for complete visibility. All the taggable users must be available in Active
Directory (AD).

Width:

Allows defining a multi-level approval hierarchy with dynamic levels (up to 10).
Each level includes a TAT (in hours or days).
Approvers can be added using @ tagging.
Depth:

System computes overall TAT by summing all levels.
TAT timer starts only when a level becomes active — delays are isolated per level.
Displays real-time Approval Flow Summary and TAT Summary for transparency.
7.7 Create New Request – Participants & Access
The system allows adding Spectators — users who can view the workflow, add comments, and
stay informed , but cannot approve or modify the request. Spectators can be added using
the “@” tag , ensuring relevant stakeholders remain in the loop throughout the approval process.

Width:

Allows adding Spectators who can view and comment but cannot approve.
Ensures visibility is restricted to participants and spectators only.
Depth:

@ tagging used to add spectators easily.
Spectators can add comments but have no edit or approval privileges.
All changes are logged in the audit trail.
7.8 Create New Request – Documents & Attachments
In this step, users can upload supporting documents and reference materials required for the
workflow request. The system supports file formats such as PDF, Word, Excel, PowerPoint, and
images , with a maximum upload size of 10 MB per file.

Users can drag and drop files directly into the upload area or use the Browse Files option to
attach them.

PDF and image files can be previewed directly within the system.
Other formats such as Word, Excel, or PowerPoint must be downloaded to view.
Additionally, users can associate Google Docs and Google Sheets links as part of the
request for collaborative reference.
This feature ensures that all relevant documents are easily accessible and centralized for
smoother review and approval.

Width:

Supports uploads of PDF, Word, Excel, PowerPoint, and image files (up to 10 MB each ).
Allows linking of Google Docs and Google Sheets.
Depth:

Provides inline preview for PDFs and images.
Other formats must be downloaded to view.
Stores file metadata (name, size, uploader, timestamp) for traceability.
7.9 Create New Request – Review & Submit
This is the final step before the request enters the approval cycle. Users can review all captured
details and ensure the accuracy of every input. The screen provides a structured summary of:

Request Overview: Displays key attributes such as Request Type, Priority, Workflow
Type, and Request Title.
Basic Information: Shows the request description and priority level entered earlier.
Approval Workflow: Summarizes approval hierarchy, approvers, and defined TAT for
each level.
Participants & Access Control: Lists spectators, permissions, and comment settings.
After verification, the user can either save the request as draft or click “Submit Request.” Once
submitted, the workflow is activated, and notifications are automatically triggered to all
assigned approvers and spectators.

This final step ensures each request is validated, structured, and complete before moving into
execution.

Width:

Displays a complete summary of all entered details before submission:
o Request Overview
o Basic Information
o Approval Workflow
o Participants & Access
Provides options to Save as Draft or Submit Request.
Depth:

Performs final validation of all required fields.
Computes total TAT and confirms approver hierarchy.
Upon submission, sends notifications to approvers and spectators.
7.10 Notifications
The system provides real-time notifications to keep users informed about workflow activities
and pending actions. Notifications appear through a bell icon in the application header with a
visible count of unread alerts.

Users receive updates such as:

Approval Reminders: Alerts when a request requires action or when its SLA/TAT is about
to expire.
Comments and Mentions: Notifications when someone adds a comment or tags the user
in a workflow discussion.
Each notification includes the request ID, message, and timestamp , allowing users to respond
quickly and maintain timely workflow progress.

Width:

Centralized bell icon for all system alerts with unread count.
Covers events like:
o Approval assignments
o SLA/TAT warnings
o Comments or mentions
o Status updates and closures
Depth:

Delivers real-time in-app alerts (optional email integration).
Each alert includes request ID, event type, user, and timestamp.
Supports click navigation , read/unread states , and auto-cleanup of old alerts.
Highlights high-priority or SLA-related notifications distinctly.
7.11 My Requests.............................................................................................................
This screen allows users to view, track, and manage all workflow requests they have created
within the system. It provides a consolidated view of request status, type, and progress for easy
monitoring.

Width:

Displays all workflow requests submitted by the logged-in user , categorized as Total, In
Progress, Approved, Rejected, and Draft.
Each record shows critical details like Request Title, Priority (Express/Standard),
Template Type, ID, Submission Date, and Current Level.
Includes search and filter options for status and priority to quickly locate specific
requests.
Depth:

Each request card provides real-time tracking of the current approver , workflow level ,
and estimated completion date.
Supports click navigation to open the detailed workflow view.
Uses color-coded indicators for status identification (e.g., green for Approved, red for
Rejected, yellow for Pending).
Data refreshes upon page load when new requests are created or status updates occur,
ensuring users always see the latest information.
7.12 Request Detail View
This screen allows users to view, review, and act on individual workflow requests. It
consolidates all key information — request details, approver actions, documents, and activity
logs — into a single, interactive view for efficient decision-making.

Width:

Displays comprehensive request details , including title, description, initiator info,
department, and contact details.
Shows priority , TAT progress bar , and remaining time until the TAT expires.
Provides a tab-based layout for:
o Overview (request details and status)
o Workflow (approval hierarchy and progress)
o Documents (uploaded files)
o Activity (comments and action log)
Includes Quick Actions for approvers: Add Work Note, Add Approver, Add Spectator,
Approve Request, and Reject Request.
Lists Spectators with view-only access.
Depth:

TAT progress bar dynamically updates based on elapsed and remaining time, color-coded
for urgency (e.g., red for nearing expiry).
Each action (approval, rejection, addition of approver/spectator) is logged in
chronology within the activity tab for full traceability.
Approvers can add comments or attachments before taking a decision.
When the request reaches its final approver , the system allows closure and triggers an AI-
generated conclusion remark summarizing the discussion (as per feedback notes).
Page refresh updates data to reflect new comments, document uploads, or action
changes.
7.13 Request Detail view - Workflow
This screen provides a stage-by-stage view of the approval hierarchy within a specific workflow.
It helps users and approvers track progress, review comments, and monitor TAT (Turnaround
Time) performance at each approval level.

Width:

Displays each approver level , showing their name, designation, and TAT allocation.
Shows real-time progress of approvals — Completed, Pending, Waiting, or Approaching
Deadline.
Includes TAT tracking with both elapsed and remaining time indicators.
Highlights whether each step was completed within or beyond TAT.
Lists approver comments for visibility and decision traceability.
Auto-sends system-generated reminders when TAT thresholds are reached (e.g., 50% or
100% usage).
Depth:

The system tracks individual TAT usage per approver level , ensuring delays are isolated
to that stage only.
TAT bars dynamically update color (e.g., green for Within TAT , yellow for Approaching
Deadline , red for Breached ).
Automatically sends TAT reminders based on configured thresholds — manual reminders
are disabled as per design notes.
Supports chronological logging of every action and comment, visible in the activity trail.
Approvers can add notes, attach files, or escalate to higher levels if TAT expires without
action.
The final approver’s action closes the workflow , triggering summary notifications and AI-
generated closure remarks.
7.14 Request Detail view - Document
This tab provides a centralized space to view, manage, and access all documents attached to the
workflow request. It ensures that approvers and spectators have visibility into all supporting
materials necessary for informed decision-making.

Width:

Displays a list of uploaded documents associated with the request, showing:
o File name , size , type/category , uploader , and timestamp.
Supports standard file types such as PDF, Word, Excel, PowerPoint, and images.
Allows users to preview or download files directly from the list.
PDF and image files can be previewed inline ; other file types must be downloaded.
Shows Quick Actions (e.g., Add Work Note, Add Approver, Add Spectator ) on the side
panel for easy context switching.
Depth:

Ensures document version integrity — if the same file name is uploaded again, the latest
version is timestamped and saved separately.
Records audit entries whenever a file is uploaded, deleted, or viewed.
Provides metadata-based filtering (by file type, uploader, or date).
Allows association of Google Docs and Google Sheets links for live collaboration.
Refreshes file list upon page load or when a new document is uploaded , ensuring users
always view the most updated set of attachments.
7.15 Request Detail view – Activity
The Activity Tab serves as a chronological timeline that records every action, event, and update
associated with a workflow request. It provides complete transparency for users to trace
approvals, comments, document uploads, and system-generated notifications.

Width:

Displays a real-time activity timeline , including events such as:
o Request creation
o Approvals and rejections
o Comments and notes added
o Document uploads or deletions
o System-generated TAT warnings or reminders
Each activity entry shows:
o Event type , description , timestamp , and initiator name.
Differentiates between user actions (e.g., “Document Added”) and system events (e.g.,
“TAT Warning Sent”).
Depth:

Activities are displayed in reverse chronological order , with the latest updates at the top.
Color-coded event icons visually represent action types (e.g., green for approval, red for
warnings).
Automatically logs system-generated events such as TAT breach alerts or reminder
dispatches.
Records file uploads with metadata (file name, uploader, timestamp) for audit
traceability.
Ensures immutable logging — entries cannot be modified or deleted once created.
Data refreshes upon page load , ensuring users always view the most updated timeline.
7.16 Add Work Note
The Work Notes section enables participants to communicate and collaborate directly within a
workflow request , ensuring that all discussions, clarifications, and shared files remain tied to the
request record. This eliminates dependency on external email threads and improves traceability.

Width:

Displays a chronological chat-style conversation between workflow participants.
Supports @mentions to tag users for feedback or updates.
Allows file sharing within messages — uploaded files appear as inline attachments with
download options.
Each message displays the sender’s name, role, timestamp, and message content.
Offers reaction options
Includes a message composer at the bottom with:
o Text box for entering messages (max 2000 characters).
Automatically differentiates roles using colored badges (e.g., Initiator, Approver,
Spectator ).
Depth:

Messages are displayed in reverse chronological order , preserving a clear dialogue
history.
@mentions trigger system notifications to the tagged users.
Each message is time-stamped, immutable, and stored as part of the request’s
permanent record.
Inline attachments are linked to the Documents Tab for centralized access.
Priority tags (e.g., P – Priority ) appear inline when approvers mark messages as urgent.
The chat interface automatically refreshes upon page load to reflect the latest messages
and reactions.
Chat data remains available throughout the workflow lifecycle and is archived upon
closure.
If there is a query at any level, user will mention it here and ask additional details.
7.17 Add Approver & Spectator
This feature allows users to add new participants —either as Approvers or Spectators —to an
ongoing workflow request. It provides flexibility for dynamically updating the workflow hierarchy
or visibility list during the approval process.

Width:

Displays a modal popup titled “Add Approver” or “Add Spectator,” depending on the
selected action.
Provides a single input field for email address entry using the @ mention convention.
Allows users to search and add participants by email or username.
Includes two action buttons: Confirm (Add) and Cancel.
Approvers: Gain the ability to review, approve, or reject the request.
Spectators: Gain view-only access with the ability to comment and receive notifications.
Both participant types receive automated notifications upon being added.
Depth:

The Approver is inserted into the approval hierarchy in the defined sequence;
the Spectator is added to the visibility list.
All additions are recorded in the activity timeline for audit and transparency.
Notifications are sent automatically to the newly added users via the system’s alert
service.
Approver TAT begins only when their stage becomes active in the workflow.
The popup closes automatically upon successful addition, refreshing the request view to
reflect the change.
7.18 Approve / Reject Request (Popup Window)
This feature enables approvers to write their decision on a workflow request by either
approving or rejecting it. It ensures that each decision is properly documented with remarks,
creating a transparent and traceable approval trail.

Width:

Displays a modal window titled “Approve Request” or “Reject Request.”
Shows key request information:
o Request ID
o Request Title
o Action Type ( Approve or Reject ).
Includes a mandatory Comments & Remarks field (up to 500 characters) for justifying the
decision.
Contains two buttons:
o Approve Request / Reject Request — confirms and submits the decision.
o Cancel — closes the modal without any action.
Shows a contextual message:
o Approval Confirmation for approval flow.
o Rejection Guidelines encouraging constructive feedback.
Depth:

Comments are mandatory for both approval and rejection to ensure context for future
reference.
Upon approval:
o The system forwards the request to the next approver in the hierarchy or closes
it if this is the final level.
o If the final approver needs to consult with someone, he can use work note to
specify that user, conclude and put the final closing remarks
o Status updates automatically across all linked screens.
Upon rejection:
o The system sends a notification to the initiator along with rejection remarks.
o The request is marked as “Rejected” and closed for further approval.
All actions are logged in the Activity Tab with timestamps and user details.
The popup automatically closes upon successful submission , refreshing the view to
display the updated status.
7.19 Closure Remark
This stage marks the final closure of a workflow request after all approvals are completed.
Once the final approver submits their decision, the request automatically returns to the
Initiator with an AI-generated Conclusion Remark summarizing the entire workflow journey.

The Initiator reviews, optionally edits, and marks the request as closed , completing the
lifecycle.

Width:

Becomes available after the final approver’s action is recorded.
Displays an AI-generated Conclusion Remark summarizing:
o Discussion highlights and decision points
o Key approval or rejection reasons
o Notable attachments or supporting references
Allows the Initiator to review and, if required, edit or enhance the remark before final
closure.
Once confirmed, the request status changes to “Closed” , and the final remark becomes
part of the permanent workflow record.
The Conclusion Remark is visible under:
o My Requests (Approved)
o Open Requests
o Closed Requests
If no remark exists, a placeholder message is displayed:
“No conclusion remarks added yet. This section will highlight the main points or core
conclusions of the request.”
Depth:

The AI engine compiles the initial remark using inputs from Work Notes, Approver
Comments, and Activity Logs.
The remark generation occurs immediately after the final approval action is completed.
The Initiator can make final edits or confirmations before closing the request.
Once marked as closed, the remark becomes read-only for all other participants and
spectators.
The finalized conclusion is stored with workflow metadata for audit, compliance, and
reporting.
Closed requests retain full visibility of their conclusion remarks for traceability and
knowledge retention.
8 Client Feedback Log (Post-Review Updates)
This section tracks all client-driven changes, clarifications, or design validations received after
initial wireframe or SRS review. Each point is linked to the relevant feature section for traceability.

# Client Request / Feedback Response / Action Taken (Rohit) Linked
Feature
Section
1 Remove the TAT
modification option for
approvers, allowing only during
initiation.
Accepted – TAT edit will be available
only at request initiation, not at
approval stages.
Approval
Workflow
2 Display Conclusion
Remarks in My Requests for
approved requests, consistent
with Open and Closed Requests.
Agreed – Will be implemented during
development. To align with design
limitation noted in section 6.20.
My Requests,
Conclusion
Remark
3 Need to see how conclusion
workflow works ; final approver
should have ability to enter
conclusion.
Confirmed – After final approval,
request returns to initiator with AI-
generated comments for review/edit
before closure.
Conclusion
Remark
4 Add restrictive view for sharing
approved requests with non-
participants.
Accepted – To be managed via Work
Notes option with permission control.
Work Notes
5 Clarify sharing and
download permissions for
requests.
Approved – Requests can be shared
internally using Add
Spectator. Download option will be
enabled for Work Notes attachments
only.
Add
Participant,
Work Notes
9 Non-Functional Requirements
Category Requirement
Performance Average response time < 3 seconds for standard operations.
Scalability Should scale horizontally on GCP.
Security JWT tokens, encrypted passwords, HTTPS enforced.
Usability Intuitive UI, consistent icons, and simple navigation.
Reliability 99% uptime target.
Backup & Recovery Daily database backup and weekly full snapshot.
Compliance Follows RE IT data privacy guidelines.
10 Technology Matrix
Component Specification
Database PGSQL (Managed or local instance)
Application Stack Node.js (Backend) + React.js (Frontend)
Authentication RE SSO Bridge
11 Infra requirements & System Hygiene
Component Specification
Environment QA / Testing
# of Virtual Machines (VMs) 1
CPU Configuration 4 - Core
Memory (RAM) 16 GB
Disk Size 500 GB
Operating System Ubuntu 24.04 LTS
Storage Type Cloud
Backup and Recovery

Daily incremental and weekly full backups.
Restore process must not exceed 2 hours.
12 Not in scope
Anything which comes beyond the scope defined above in terms of Width and depth