RE_Documents/streamline_questions.md

15 KiB

RE Workflow Management - Clarification Questions

Non-Templatized Approval Workflows


1. @Mention Behavior in Work Notes

Q1. If someone @mentions a user who is NOT a participant in Work Notes, what happens?

  • Option A: Auto-add them as a Spectator?
  • Option B: Send notification but don't add them?
  • Option C: Show error and prevent the mention?
  • Option D: Require explicit approval to add?

Decision: _______________________


2. Sequential vs Parallel Notification & Visibility

Q2.1 When a request is submitted, who receives notifications?

  • Option A: Only the first approver (sequential)
  • Option B: All approvers and spectators (simultaneous)

Q2.2 Can Approver Level 2 see the request before Level 1 approves it?

  • Option A: No - it appears only when it reaches their level
  • Option B: Yes - but marked as "Waiting for Level 1" and action buttons disabled

Q2.3 What appears in "Open Requests" for different approvers?

  • For Level 1 Approver: Shows as "Action Required"
  • For Level 2 Approver (before Level 1 acts):
    • Option A: Request doesn't appear at all
    • Option B: Shows as "Waiting for previous level"

Decision: _______________________


3. Request Creation - Alert & Notification System

Q3.1 - Initiator Notifications After Submission

When initiator submits a request, what notifications/alerts do they receive?

  • Immediate confirmation:

    • In-app notification: "Your request #12345 has been submitted successfully"
    • Email confirmation with request summary and tracking link?
    • Both?
  • Request submitted to whom:

    • "Your request has been sent to [Approver Name] for Level 1 approval"?
    • Show approver name and expected TAT?

Decision: _______________________


Q3.2 - First Approver Notification

When request is submitted, what does the FIRST approver receive?

Notification Content:

  • "New approval request #12345 from [Initiator Name]"
  • Include request title?
  • Include priority (Express/Standard)?
  • Include TAT deadline date/time?
  • Direct link to approve/view request?

Notification Channels:

  • In-app notification (bell icon)?
  • Email notification?
  • Both?

Notification Timing:

  • Immediate (within seconds of submission)?
  • Batched (every 15 mins, every hour)?

Decision: _______________________


Q3.3 - Spectator Notifications After Submission

When request is submitted, what do SPECTATORS receive?

Notification Content:

  • "You've been added as a spectator to request #12345"?
  • Include request summary and purpose?
  • Link to view request?

Notification Channels:

  • In-app notification?
  • Email notification?
  • Both?

Can spectators opt-out of notifications:

  • Yes - they can mute specific requests?
  • No - mandatory notifications?

Decision: _______________________


Q3.4 - Draft Auto-Save Notifications

When user is creating a request (before submission):

  • Auto-save behavior:

    • Auto-save every 30 seconds?
    • Auto-save on field change (debounced)?
    • Manual save only?
  • Auto-save notification:

    • Show "Saved as draft" toast message?
    • Show "Last saved at 10:45 AM" timestamp?
    • Silent save (no notification)?
  • Draft recovery:

    • If user closes browser, show "You have an unsaved draft" on next login?
    • Auto-recover draft?

Decision: _______________________


4. Approval Process - Notification & Alert Flow

Q4.1 - Approver Action Required Reminders

When a request is pending at an approver's level:

Initial Notification:

  • Sent immediately when request reaches their level?
  • Include TAT deadline?

Reminder Schedule (if no action taken):

  • Reminder at 50% TAT elapsed?
  • Reminder at 75% TAT elapsed?
  • Reminder at 90% TAT elapsed?
  • Reminder at 100% TAT (deadline reached)?
  • Reminder at 110% TAT (breached)?

Reminder Frequency After Breach:

  • Daily reminder after TAT breach?
  • Every 12 hours?
  • No more reminders after initial breach notification?

Escalation After Multiple Reminders:

  • After 3 reminders with no action, notify approver's manager?
  • Auto-escalate to next level after X hours of inactivity?
  • No auto-escalation, just keep reminding?

Decision: _______________________


Q4.2 - TAT Approaching/Breached Visual Indicators

For approvers viewing their pending requests:

Visual Indicators:

  • Color-coded TAT bar:

    • Green: Within 50% TAT
    • Yellow: 50-90% TAT elapsed
    • Orange: 90-100% TAT elapsed
    • Red: TAT breached
  • TAT countdown timer:

    • "2 hours 30 minutes remaining"
    • "Due in 2 days"
    • "Overdue by 5 hours" (if breached)
  • Badge on request card:

    • "URGENT" badge if approaching deadline?
    • "OVERDUE" badge if breached?

Sorting Priority:

  • Auto-sort pending requests by TAT urgency (most urgent first)?
  • Separate "Overdue" section at top?

Decision: _______________________


Q4.3 - Approval Action Confirmation

When approver clicks "Approve" button:

Confirmation Required:

  • Show confirmation popup before approving?

    • "Are you sure you want to approve request #12345?"
    • "This action cannot be undone" (or can it?)
  • Or immediate approval (no confirmation)?

Mandatory Comments:

  • Must approver enter comments when approving?
  • Or comments optional on approval (mandatory only on rejection)?

After Approval Action:

  • Show success message: "Request approved successfully"?
  • Redirect to next pending request?
  • Stay on same request to see updated status?

Decision: _______________________


Q4.4 - Who Gets Notified When Level 1 Approves?

When Level 1 approver APPROVES the request:

Notifications Sent To:

  • Initiator:

    • "Your request #12345 has been approved by [Approver 1 Name]"?
    • Include approver's comments?
    • Notify that it's moving to Level 2?
  • Level 2 Approver:

    • "New approval request #12345 is now awaiting your action"?
    • Include Level 1 approval comments?
    • Include updated TAT for their level?
  • Spectators:

    • "Request #12345 approved by Level 1, now at Level 2"?
    • Or silent update (no notification)?
  • Previous Approvers (Level 1):

    • Confirmation notification: "Your approval for #12345 has been recorded"?
    • Or no notification after action taken?

Notification Channels:

  • In-app notification?
  • Email notification?
  • Both?

Decision: _______________________


Q4.5 - Who Gets Notified When Approver REJECTS?

When ANY approver REJECTS the request:

Notifications Sent To:

  • Initiator:

    • "Your request #12345 has been rejected by [Approver Name]"?
    • Include rejection reason/comments (mandatory)?
    • Include what actions initiator can take (resubmit, modify, close)?
  • All Spectators:

    • "Request #12345 has been rejected"?
    • Include rejection reason?
  • Previous Approvers:

    • Notify that request was rejected downstream?
    • Or no notification (workflow ended)?
  • Subsequent Approvers (Level 3, 4...):

    • Remove request from their pending list?
    • Notify that request was rejected before reaching them?

Rejection Behavior:

  • Request immediately closed (cannot be reopened)?
  • Request goes back to initiator as "Draft" for modification?
  • Request goes back to previous approver level?

Decision: _______________________


Q4.6 - Final Approval & Closure Notifications

When FINAL approver approves (last level in hierarchy):

Notifications Sent To:

  • Initiator:

    • "Your request #12345 has been fully approved!"?
    • Include AI-generated conclusion summary?
    • Prompt to add closure remarks?
  • All Previous Approvers:

    • "Request #12345 has completed all approvals"?
    • Or no notification?
  • All Spectators:

    • "Request #12345 has been fully approved and closed"?

Closure Workflow:

  • Request automatically marked as "Approved" (closed)?
  • Request returns to initiator for final closure remarks?
  • Initiator must explicitly mark as "Closed" after reviewing?

Conclusion Remark:

  • AI-generated conclusion sent immediately to initiator?
  • Generated when initiator opens closure screen?
  • Initiator can edit/regenerate AI conclusion?

Decision: _______________________


5. Approval Process - Mid-Workflow Actions

Q5.1 - Adding Approver Mid-Workflow

If an approver wants to add another approver at their level or before their level:

Behavior:

  • Insert Before Current Level:

    • New approver added between Level 1 and Level 2?
    • Request goes back to new approver?
    • Or new approver acts in parallel?
  • Add at Current Level (Parallel):

    • Both must approve before moving to next level?
    • Or either can approve?
  • Add After Current Level:

    • New approver added as Level 3 (shifting existing levels)?

Notifications:

  • Notify new approver immediately?
  • Notify initiator that approval hierarchy changed?
  • Notify all spectators?

TAT Impact:

  • Does adding new approver extend total TAT?
  • Or new approver shares existing level TAT?

Decision: _______________________


Q5.2 - Request Stuck at Approver (TAT Breached)

When request TAT is breached at an approver level:

Auto-Actions:

  • Auto-escalate to approver's manager:

    • Notify manager to follow up?
    • Manager can approve on behalf?
    • Or manager can only remind?
  • Auto-reassign to alternate approver:

    • If primary approver is inactive/on leave?
    • Based on delegation rules?
  • No auto-action:

    • Just send repeated reminders?
    • Manual escalation required?

Visibility:

  • Show "OVERDUE" badge to all participants?
  • Send escalation notification to initiator?
  • Notify admin/system owner?

Decision: _______________________


Q5.3 - Approver on Leave/Unavailable

If assigned approver is on leave when request reaches them:

System Behavior:

  • Check leave calendar:

    • System checks if approver is on leave?
    • Auto-skip to delegate if on leave?
  • Delegation mechanism:

    • Does approver pre-configure delegate before going on leave?
    • Auto-delegate to manager if no delegate configured?
    • Or request stays pending until approver returns?
  • No delegation:

    • Request stays pending (TAT keeps running)?
    • Show warning: "Approver is currently on leave"?

Notifications:

  • Notify delegate when request is auto-delegated?
  • Notify initiator about delay due to leave?

Decision: _______________________


6. Notification Preferences & Settings

Q6.1 - User Notification Preferences

Can users customize which notifications they receive?

Customization Options:

  • Turn off email notifications:

    • Receive only in-app notifications?
    • Turn off entirely (not recommended)?
  • Notification frequency:

    • Immediate (real-time)?
    • Digest (once per day summary)?
    • Custom frequency?
  • Notification types:

    • Opt-out of spectator notifications?
    • Only notify for urgent requests?
    • Only notify for requests where I'm approver (not spectator)?

Default Settings:

  • All notifications ON by default?
  • User can change in profile settings?

Decision: _______________________


Q6.2 - Notification Delivery Failure Handling

If notification fails to deliver (email bounces, user not found):

System Behavior:

  • Retry delivery (how many times)?
  • Log failed notification?
  • Alert admin/system owner?
  • Show warning in UI: "Email notification failed to send"?

Fallback:

  • If email fails, ensure in-app notification works?
  • SMS notification as fallback (if configured)?

Decision: _______________________


7. Bulk Operations & Multiple Requests

Q7.1 - Approver with Multiple Pending Requests

If an approver has 10+ requests pending:

Bulk Actions:

  • Can approver approve multiple requests at once:

    • Select 5 requests → Click "Approve All"?
    • Or must approve each individually?
  • Bulk comments:

    • Single comment applied to all selected requests?
    • Or individual comments required?

Sorting/Filtering:

  • Sort pending requests by TAT urgency?
  • Filter by priority (Express first)?
  • Group by initiator/department?

Decision: _______________________


Q7.2 - Notification Batching

If many actions happen in short time (e.g., 5 requests submitted to same approver in 5 minutes):

Notification Behavior:

  • Send individual notifications:

    • 5 separate emails/notifications?
  • Batch notifications:

    • Single notification: "You have 5 new approval requests"?
    • Batching window: 15 minutes?
  • Smart batching:

    • If >3 notifications in 10 mins, batch them?

Decision: _______________________


8. Edge Cases & Error Scenarios

Q8.1 - Request Submitted with No Approvers

If user tries to submit request without defining any approvers:

System Behavior:

  • Block submission with error: "At least one approver required"?
  • Allow submission (self-approved workflow)?
  • Auto-assign default approver (manager)?

Decision: _______________________


Q8.2 - Approver Approves Then Tries to Undo

If approver accidentally approves and wants to undo:

Undo Mechanism:

  • Grace period for undo:

    • Allow undo within 5 minutes?
    • Show "Undo Approval" button for 5 mins?
  • No undo:

    • Once approved, cannot undo?
    • Must contact admin/system owner?
  • Undo conditions:

    • Can only undo if next level hasn't acted yet?
    • Cannot undo if workflow moved forward?

Decision: _______________________


Q8.3 - Notification System Down

If notification service (email/in-app) is temporarily down:

System Behavior:

  • Queue notifications for retry?
  • Log missed notifications?
  • Show banner: "Notifications are temporarily unavailable"?
  • Send catch-up notifications when service restores?

Decision: _______________________


Summary: Decisions Required

This document contains 30+ clarification questions specifically about:

  • Request creation alerts (Q3.1 - Q3.4)
  • Approval process notifications (Q4.1 - Q4.6)
  • Mid-workflow actions (Q5.1 - Q5.3)
  • Notification preferences (Q6.1 - Q6.2)
  • Bulk operations (Q7.1 - Q7.2)
  • Edge cases (Q8.1 - Q8.3)

Next Steps:

  1. Review each question with stakeholders
  2. Make decisions and document
  3. Update technical specifications accordingly
  4. Design notification architecture based on decisions

Document Owner: Development Team
Status: ⚠️ AWAITING STAKEHOLDER DECISIONS
Priority: 🔴 HIGH - Affects core user experience and system behavior