547 lines
15 KiB
Markdown
547 lines
15 KiB
Markdown
# 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 |