Scenario Email Optional Implementation
Overview
This document describes the implementation that makes email notifications optional for scenarios based on their source (user-created vs radar-generated).Problem Statement
Previously, ALL completed scenarios would trigger email notifications to users. This was problematic for radar-generated scenarios, which are automated background processes that shouldn’t spam users with emails.Solution Architecture
Flow Diagram
Changes Made
1. Frontend - Chat Tools (app/api/chat/tools.ts)
Change: Added source parameter to createScenario tool
'user' if not specified
2. Radar Feed Directive (app/api/radar/silvia-simulation/route.ts)
Change: Updated system directive to instruct LLM to pass source
3. Lambda API Handler (aws/scenarios/lambdas/api/handler.py)
Changes:
- Accept source parameter from request body
- Store in DynamoDB consultation item
- Pass through SQS message
'user' if not provided
4. Lambda Agent Processor (aws/scenarios/lambdas/agent_processor/handler.py)
Change: Conditionally send emails based on source
'user' (sends email) if not specified
Testing Checklist
Manual Testing
- Create user scenario from UI → Should receive email
- Create user scenario from chat → Should receive email
- Radar generates scenario → Should NOT receive email
- Check DynamoDB to verify source field is stored
- Check CloudWatch logs for email skip message
Edge Cases
- Scenario created before this change (no source field) → Should receive email (backward compatible)
- Scenario with invalid source value → Should receive email (defaults to ‘user’)
- Multiple radar scenarios generated → Should not receive multiple emails
Deployment Notes
Prerequisites
- No database migrations needed (DynamoDB is schemaless)
- No infrastructure changes needed
- Fully backward compatible
Deployment Order
- Deploy Lambda functions (API handler + Agent processor)
- Deploy Next.js application (frontend changes)
- No downtime required
Rollback Plan
If issues occur:- Revert Lambda deployments
- Revert Next.js deployment
- All scenarios will default to sending emails (safe fallback)
Monitoring
Key Metrics
- Email send rate (should decrease after deployment)
- Radar scenario completion rate
- User scenario completion rate
- Email API success rate
CloudWatch Logs
Search for:"Skipping email notification for radar-generated scenario"- Radar scenarios"Sending email notification for consultation"- User scenarios
Benefits
- Better UX: Users no longer receive spam emails from automated radar scenarios
- Cost Savings: Fewer emails sent = lower email service costs
- Clean Separation: Clear distinction between user-initiated and automated scenarios
- Extensible: Easy to add more source types in the future (e.g., ‘scheduled’, ‘webhook’)
- Backward Compatible: Existing scenarios and workflows unchanged
Future Enhancements
Potential improvements:- Add email preferences per source type in user settings
- Track source in analytics/metrics
- Add source filter in scenarios UI
- Support batch email digest for radar scenarios