I asked Claude to plan my weekly ServiceNow Developer Schedule:
Monday — Sprint Planning & Scripting
Time
Task
Example Work
9:00 AM
Stand-up & sprint planning
Review backlog tickets, assign story points, discuss blockers. Example: prioritizing a Flow Designer automation for HR onboarding.
10:00 AM
Client script development
Write an onChange client script to auto-populate the Assignment Group field based on category selection on the Incident form.
12:00 PM
Lunch / break
—
1:00 PM
Business rule authoring
Create a “before insert” business rule on the Problem table to enforce mandatory fields and auto-set Priority based on Impact × Urgency matrix.
3:00 PM
Unit testing scripts
Run ATF (Automated Test Framework) tests for client scripts. Validate onChange logic across multiple browsers and user roles.
4:30 PM
End-of-day notes
Update story comments in the ServiceNow SDLC app. Document script logic, scope, and edge cases discovered during testing.
Tuesday — Flow Designer & Integrations
Time
Task
Example Work
9:00 AM
Stand-up
Share daily progress. Example: report that HR onboarding flow is 60% complete, flag approval step dependency.
9:30 AM
Flow Designer workflow build
Build an HR onboarding flow: trigger on new employee record, auto-create tasks for IT, Facilities, and HR, send approval to manager, provision access.
11:30 AM
REST API integration
Create a REST Message record to connect ServiceNow to an external payroll system. Write a scripted REST API call using GlideHTTPRequest to push employee data.
12:30 PM
Lunch / break
—
1:30 PM
Integration testing
Test REST API payload using the REST API Explorer. Validate JSON response parsing and error handling in Transform Maps.
3:30 PM
Peer code review
Review a colleague’s Script Include for reusable CMDB query logic. Check for proper use of GlideRecord, avoid hardcoded sys_ids, add inline comments.
4:30 PM
Documentation update
Write technical design notes for the integration: endpoint, auth method, payload structure, and error codes.
Wednesday — CMDB & Service Catalog
Time
Task
Example Work
9:00 AM
Stand-up
Discuss CMDB data quality findings from the previous day’s Discovery run. Flag duplicate CI records.
9:30 AM
CMDB relationship mapping
Define CI relationships between Application CIs and Server CIs. Use the Dependency View map to validate Business Service impact chains.
11:00 AM
Service Catalog item build
Build a “New Software Request” catalog item with variable sets for requestor info, software name, business justification, and approval routing via Flow Designer.
12:30 PM
Lunch / break
—
1:30 PM
Discovery configuration review
Review MID Server logs, confirm IP ranges are scanned, check Probe/Sensor results for Windows servers. Resolve classification errors.
3:00 PM
Catalog testing & QA
Submit test requests as end-user role. Verify variable rendering, approval routing, task generation, and notifications fire correctly.
4:30 PM
Update user stories
Mark catalog item tasks done, add acceptance criteria notes, link test evidence to SDLC stories.
Thursday — ITSM Workflows & Notifications
Time
Task
Example Work
9:00 AM
Stand-up
Demo completed catalog item to product owner for quick feedback before sprint review.
9:30 AM
Assignment rule configuration
Create Assignment Rules to auto-route Incidents by category: Network issues → Network Ops group, HR issues → HR Help Desk group.
11:00 AM
Notification & email template build
Create HTML email notifications for Incident assigned, SLA breach warning, and Problem resolved events. Use ${variable} syntax for dynamic fields.
12:30 PM
Lunch / break
—
1:30 PM
SLA definition & configuration
Configure a P2 Incident SLA: 4-hour response, 8-hour resolution. Set conditions, schedule (business hours), and pause conditions for Pending/On Hold states.
3:00 PM
SLA & notification testing
Create test incidents of each priority. Confirm SLA timers start/pause/stop correctly. Verify emails land in test inbox with correct dynamic data.
4:30 PM
Sprint review prep
Prepare a short summary of completed work for Friday review: screenshots, demo flows, and notes on any open items.
Friday — Sprint Review, Refactoring & Learning
Time
Task
Example Work
9:00 AM
Sprint review meeting
Demo completed stories to stakeholders: show catalog item, Flow Designer workflow, SLA config, and integration. Gather feedback.
10:30 AM
Retrospective
Team discusses what went well (Flow Designer efficiency) and what to improve (more test coverage on business rules next sprint).
11:00 AM
Code refactoring & cleanup
Refactor business rules to use Script Includes instead of inline code. Extract reusable functions into an IncidentUtils Script Include for DRY compliance.
12:30 PM
Lunch / break
—
1:30 PM
Learning & certification study
Study for CSA or CAD exam. Review Flow Designer documentation, practice GlideRecord queries in a personal dev instance (PDI).
3:00 PM
Content creation / knowledge share
Write a LinkedIn post or internal wiki article: “How we automated HR onboarding in Flow Designer — 3 lessons learned.”
4:30 PM
Week wrap-up & next sprint prep
Review upcoming backlog. Groom new stories, estimate effort, confirm dependencies with the team before Monday planning.
Weekly Focus Areas at a Glance
Day
Primary Focus
Key Technologies
Monday
Sprint planning & scripting
Client Scripts, Business Rules, ATF
Tuesday
Automation & integrations
Flow Designer, REST API, Transform Maps
Wednesday
Data & self-service
CMDB, Discovery, Service Catalog
Thursday
ITSM configuration
Assignment Rules, SLAs, Notifications
Friday
Review, refactoring & growth
Script Includes, Certification, Content
A few things to note about how a real ServiceNow developer’s week flows:
The rhythm — mornings are for building (scripts, flows, integrations), afternoons for testing and review, and end-of-day for documentation. This keeps context-switching low.
The mix of work types — a single week typically touches client scripts, business rules, Flow Designer, REST APIs, CMDB, Service Catalog, ITSM configuration (SLAs, assignments, notifications), and ATF testing. No two days are the same module.
Friday is intentionally lighter — sprint ceremonies in the morning, refactoring in the afternoon, and time carved out for certification study and knowledge sharing. This is where your content creation work (LinkedIn posts, tutorials, internal wikis) fits naturally into the developer routine.