snow-flow 4.2.3 → 4.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CLAUDE.md +918 -0
- package/dist/cli.js +1 -91
- package/package.json +1 -1
- package/check-mcp-resources.sh +0 -85
- package/cloudbuild-npm.yaml +0 -132
- package/cloudbuild-website.yaml +0 -92
- package/cloudbuild.yaml +0 -141
- package/empty-test.json +0 -3
- package/fix-console-logs.sh +0 -32
- package/fix-mcp-responses.sh +0 -31
- package/simple-test.json +0 -9
- package/test-mcp.json +0 -11
- package/test.txt +0 -1
- package/website/cloudbuild.yaml +0 -70
package/CLAUDE.md
ADDED
|
@@ -0,0 +1,918 @@
|
|
|
1
|
+
# Snow-Flow Configuration & Best Practices
|
|
2
|
+
|
|
3
|
+
This document provides comprehensive instructions for Snow-Flow, an advanced ServiceNow development and orchestration framework powered by Claude AI.
|
|
4
|
+
|
|
5
|
+
## Table of Contents
|
|
6
|
+
1. [Core Philosophy](#core-philosophy)
|
|
7
|
+
2. [Fundamental Rules](#fundamental-rules)
|
|
8
|
+
3. [ServiceNow Development Standards](#servicenow-development-standards)
|
|
9
|
+
4. [MCP Server Capabilities](#mcp-server-capabilities)
|
|
10
|
+
5. [Debugging Best Practices](#debugging-best-practices)
|
|
11
|
+
6. [Command Reference](#command-reference)
|
|
12
|
+
7. [Workflow Guidelines](#workflow-guidelines)
|
|
13
|
+
|
|
14
|
+
## CRITICAL: Widget Debugging Must Use Local Sync
|
|
15
|
+
|
|
16
|
+
### \ud83d\udd34 When User Reports Widget Issues, ALWAYS Use `snow_pull_artifact` FIRST!
|
|
17
|
+
|
|
18
|
+
**Common scenarios that REQUIRE Local Sync:**
|
|
19
|
+
- "Widget skips questions" \u2192 `snow_pull_artifact`
|
|
20
|
+
- "Form doesn't submit properly" \u2192 `snow_pull_artifact`
|
|
21
|
+
- "Data not displaying" \u2192 `snow_pull_artifact`
|
|
22
|
+
- "Button doesn't work" \u2192 `snow_pull_artifact`
|
|
23
|
+
- "Debug this widget" \u2192 `snow_pull_artifact`
|
|
24
|
+
- "Fix widget issue" \u2192 `snow_pull_artifact`
|
|
25
|
+
|
|
26
|
+
**DO NOT use `snow_query_table` for widget debugging!** It will hit token limits and you can't use native search/edit tools.
|
|
27
|
+
|
|
28
|
+
## Core Philosophy
|
|
29
|
+
|
|
30
|
+
### The Prime Directive: Verify, Don't Assume
|
|
31
|
+
|
|
32
|
+
Snow-Flow operates on evidence-based development. Never make assumptions about what exists or doesn't exist in a ServiceNow environment. Every environment is unique with custom tables, fields, integrations, and configurations that you cannot predict.
|
|
33
|
+
|
|
34
|
+
**Cardinal Rules:**
|
|
35
|
+
1. If code references something, it probably exists
|
|
36
|
+
2. Test before declaring something broken
|
|
37
|
+
3. Verify before modifying
|
|
38
|
+
4. Fix only what's confirmed broken
|
|
39
|
+
5. Respect existing configurations
|
|
40
|
+
|
|
41
|
+
### The Verification-First Approach
|
|
42
|
+
|
|
43
|
+
```javascript
|
|
44
|
+
// Before claiming anything doesn't work or exist:
|
|
45
|
+
// Step 1: Test the actual implementation
|
|
46
|
+
const verify = await snow_execute_script_with_output({
|
|
47
|
+
script: `/* Test the exact code or resource */`
|
|
48
|
+
});
|
|
49
|
+
|
|
50
|
+
// Step 2: Check if resources exist
|
|
51
|
+
const tableCheck = await snow_discover_table_fields({
|
|
52
|
+
table_name: 'potentially_custom_table'
|
|
53
|
+
});
|
|
54
|
+
|
|
55
|
+
// Step 3: Validate configurations
|
|
56
|
+
const propertyCheck = await snow_property_manager({
|
|
57
|
+
action: 'get',
|
|
58
|
+
name: 'system.property'
|
|
59
|
+
});
|
|
60
|
+
|
|
61
|
+
// Step 4: Only then make informed decisions
|
|
62
|
+
```
|
|
63
|
+
|
|
64
|
+
### 🔄 CRITICAL: Sync User Modifications Before Working
|
|
65
|
+
|
|
66
|
+
**When a user mentions they've modified an artifact directly in ServiceNow, ALWAYS fetch the latest version first!**
|
|
67
|
+
|
|
68
|
+
If a user says any of these:
|
|
69
|
+
- "I've updated the widget in ServiceNow"
|
|
70
|
+
- "I made some changes to the flow"
|
|
71
|
+
- "I modified the script"
|
|
72
|
+
- "I adjusted the configuration"
|
|
73
|
+
- "Ik heb het zelf aangepast" (Dutch: I adjusted it myself)
|
|
74
|
+
|
|
75
|
+
**YOU MUST:**
|
|
76
|
+
|
|
77
|
+
1. **Immediately fetch the current version from ServiceNow:**
|
|
78
|
+
```javascript
|
|
79
|
+
// For any artifact the user has modified
|
|
80
|
+
const currentVersion = await snow_query_table({
|
|
81
|
+
table: 'artifact_table_name',
|
|
82
|
+
query: `sys_id=${artifact_sys_id}`,
|
|
83
|
+
fields: ['*'], // Get all fields
|
|
84
|
+
limit: 1
|
|
85
|
+
});
|
|
86
|
+
|
|
87
|
+
// Or for widgets specifically
|
|
88
|
+
const widgetData = await snow_query_table({
|
|
89
|
+
table: 'sp_widget',
|
|
90
|
+
query: `sys_id=${widget_sys_id}`,
|
|
91
|
+
fields: ['name', 'template', 'client_script', 'script', 'css', 'option_schema'],
|
|
92
|
+
limit: 1
|
|
93
|
+
});
|
|
94
|
+
|
|
95
|
+
// Or use snow_get_by_sysid for comprehensive retrieval
|
|
96
|
+
const artifact = await snow_get_by_sysid({
|
|
97
|
+
table: 'table_name',
|
|
98
|
+
sys_id: 'the_sys_id'
|
|
99
|
+
});
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
2. **Analyze the user's modifications:**
|
|
103
|
+
- Review what they changed
|
|
104
|
+
- Understand their intent
|
|
105
|
+
- Preserve their modifications
|
|
106
|
+
|
|
107
|
+
3. **Build upon their changes:**
|
|
108
|
+
- Don't overwrite their work
|
|
109
|
+
- Integrate new features with their modifications
|
|
110
|
+
- Maintain their code style and patterns
|
|
111
|
+
|
|
112
|
+
4. **Inform the user:**
|
|
113
|
+
- Acknowledge that you've fetched their latest changes
|
|
114
|
+
- Summarize what modifications you found
|
|
115
|
+
- Explain how you'll build upon their work
|
|
116
|
+
|
|
117
|
+
**Example Workflow:**
|
|
118
|
+
```javascript
|
|
119
|
+
// User: "I've updated the widget to add a loading spinner"
|
|
120
|
+
// Snow-Flow response:
|
|
121
|
+
|
|
122
|
+
// 1. Fetch current version
|
|
123
|
+
const widget = await snow_query_table({
|
|
124
|
+
table: 'sp_widget',
|
|
125
|
+
query: `sys_id=${widgetSysId}`,
|
|
126
|
+
fields: ['*'],
|
|
127
|
+
limit: 1
|
|
128
|
+
});
|
|
129
|
+
|
|
130
|
+
// 2. Analyze changes
|
|
131
|
+
console.log("✅ Fetched your latest widget version from ServiceNow");
|
|
132
|
+
console.log("📝 I see you've added a loading spinner in the template");
|
|
133
|
+
|
|
134
|
+
// 3. Work with the updated version
|
|
135
|
+
// ... make additional changes based on user's modifications ...
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
**Why This Matters:**
|
|
139
|
+
- User modifications are not tracked locally
|
|
140
|
+
- Working with outdated versions causes conflicts
|
|
141
|
+
- User's work could be lost if not synced
|
|
142
|
+
- Builds trust by respecting user's contributions
|
|
143
|
+
- Ensures coherent development flow
|
|
144
|
+
|
|
145
|
+
## Fundamental Rules
|
|
146
|
+
|
|
147
|
+
### Rule 1: ES5 JavaScript Only in ServiceNow
|
|
148
|
+
|
|
149
|
+
ServiceNow uses the Rhino JavaScript engine which supports only ES5. Modern JavaScript syntax will fail.
|
|
150
|
+
|
|
151
|
+
**Never Use:**
|
|
152
|
+
- `const` or `let` - use `var`
|
|
153
|
+
- Arrow functions `() => {}` - use `function() {}`
|
|
154
|
+
- Template literals `` `${var}` `` - use string concatenation
|
|
155
|
+
- Destructuring `{a, b} = obj` - use explicit property access
|
|
156
|
+
- `for...of` loops - use traditional `for` loops
|
|
157
|
+
- Default parameters - use `typeof` checks
|
|
158
|
+
- `async/await` - use callbacks or GlideAjax
|
|
159
|
+
- `enum` - use object literals with constants instead
|
|
160
|
+
- Classes - use function constructors with prototypes
|
|
161
|
+
- Spread operator `...` - use Array methods or loops
|
|
162
|
+
- Array methods like `map`, `filter`, `reduce` - use for loops
|
|
163
|
+
|
|
164
|
+
**Always Use:**
|
|
165
|
+
```javascript
|
|
166
|
+
// ES5 compatible code
|
|
167
|
+
var name = 'value';
|
|
168
|
+
function processData() {
|
|
169
|
+
return 'result';
|
|
170
|
+
}
|
|
171
|
+
var message = 'Hello ' + userName;
|
|
172
|
+
for (var i = 0; i < array.length; i++) {
|
|
173
|
+
var item = array[i];
|
|
174
|
+
}
|
|
175
|
+
|
|
176
|
+
// Instead of enum, use object literals:
|
|
177
|
+
var Status = {
|
|
178
|
+
PENDING: 'pending',
|
|
179
|
+
ACTIVE: 'active',
|
|
180
|
+
COMPLETED: 'completed'
|
|
181
|
+
};
|
|
182
|
+
|
|
183
|
+
// Instead of class, use function constructor:
|
|
184
|
+
function MyClass(name) {
|
|
185
|
+
this.name = name;
|
|
186
|
+
}
|
|
187
|
+
MyClass.prototype.getName = function() {
|
|
188
|
+
return this.name;
|
|
189
|
+
};
|
|
190
|
+
```
|
|
191
|
+
|
|
192
|
+
### Rule 2: Use Local Sync for Widget Debugging - NOT snow_query_table!
|
|
193
|
+
|
|
194
|
+
**CRITICAL: When debugging widgets, ALWAYS use `snow_pull_artifact` first!**
|
|
195
|
+
|
|
196
|
+
```javascript
|
|
197
|
+
// ✅ CORRECT - Use Local Sync for widget debugging
|
|
198
|
+
snow_pull_artifact({
|
|
199
|
+
sys_id: 'widget_sys_id',
|
|
200
|
+
table: 'sp_widget'
|
|
201
|
+
});
|
|
202
|
+
// Now use Claude Code native search, multi-file edit, etc.
|
|
203
|
+
|
|
204
|
+
// ❌ WRONG - Don't use snow_query_table for debugging widgets
|
|
205
|
+
snow_query_table({
|
|
206
|
+
table: 'sp_widget',
|
|
207
|
+
query: 'sys_id=...',
|
|
208
|
+
fields: ['template', 'script', 'client_script']
|
|
209
|
+
});
|
|
210
|
+
// This hits token limits and can't use native tools!
|
|
211
|
+
```
|
|
212
|
+
|
|
213
|
+
**Why Local Sync for Widget Debugging:**
|
|
214
|
+
- **No token limits** - Handle widgets of ANY size
|
|
215
|
+
- **Native search** - Find issues across all files instantly
|
|
216
|
+
- **Multi-file view** - See relationships between components
|
|
217
|
+
- **Better debugging** - Trace data flow, find missing methods
|
|
218
|
+
- **Coherence checking** - Validate all parts work together
|
|
219
|
+
|
|
220
|
+
**Widget Debugging Workflow:**
|
|
221
|
+
1. User reports issue → `snow_pull_artifact`
|
|
222
|
+
2. Search for error patterns across files
|
|
223
|
+
3. Fix using multi-file edit
|
|
224
|
+
4. Validate coherence → `snow_validate_artifact_coherence`
|
|
225
|
+
5. Push fixes back → `snow_push_artifact`
|
|
226
|
+
|
|
227
|
+
### Rule 3: Background Scripts for Verification Only
|
|
228
|
+
|
|
229
|
+
Background scripts provide immediate feedback but should NOT be used for widget updates. Use them for verification:
|
|
230
|
+
|
|
231
|
+
```javascript
|
|
232
|
+
// Use for verification and testing
|
|
233
|
+
const verify = await snow_execute_script_with_output({
|
|
234
|
+
script: `/* Test code */`
|
|
235
|
+
});
|
|
236
|
+
```
|
|
237
|
+
|
|
238
|
+
### Rule 4: Widget Coherence - Critical Client-Server Communication
|
|
239
|
+
|
|
240
|
+
ServiceNow widgets MUST have perfect communication between client and server scripts. This is not optional - widgets fail when these components don't talk to each other correctly.
|
|
241
|
+
|
|
242
|
+
**IMPORTANT: Use Local Sync Instead of Query for Large Widgets**
|
|
243
|
+
|
|
244
|
+
When you see "exceeds maximum allowed tokens" errors, don't try to fetch fields separately with `snow_query_table`. Use Local Sync instead:
|
|
245
|
+
|
|
246
|
+
```javascript
|
|
247
|
+
// ❌ WRONG - Don't do this when debugging:
|
|
248
|
+
snow_query_table({ table: 'sp_widget', fields: ['name'] });
|
|
249
|
+
snow_query_table({ table: 'sp_widget', fields: ['script'] });
|
|
250
|
+
snow_query_table({ table: 'sp_widget', fields: ['client_script'] });
|
|
251
|
+
// This is inefficient and can't use native tools!
|
|
252
|
+
|
|
253
|
+
// ✅ CORRECT - Use Local Sync:
|
|
254
|
+
snow_pull_artifact({
|
|
255
|
+
sys_id: '01d01d6983176a502a7ea130ceaad376'
|
|
256
|
+
});
|
|
257
|
+
// All files available locally with NO token limits!
|
|
258
|
+
```
|
|
259
|
+
|
|
260
|
+
**Local Sync Benefits:**
|
|
261
|
+
- Handles widgets of ANY size automatically
|
|
262
|
+
- All files available for native tool usage
|
|
263
|
+
- Maintains relationships between components
|
|
264
|
+
- Enables powerful search and refactoring
|
|
265
|
+
|
|
266
|
+
**The Three-Way Contract:**
|
|
267
|
+
|
|
268
|
+
**Server Script Must:**
|
|
269
|
+
- Initialize all `data` properties that HTML will reference
|
|
270
|
+
- Handle every `input.action` that client sends
|
|
271
|
+
- Return data in the format client expects
|
|
272
|
+
|
|
273
|
+
**Client Script Must:**
|
|
274
|
+
- Implement every method that HTML calls via `ng-click`
|
|
275
|
+
- Use `c.server.get({action: 'name'})` for server communication
|
|
276
|
+
- Update `c.data` when server responds
|
|
277
|
+
|
|
278
|
+
**HTML Template Must:**
|
|
279
|
+
- Only reference `data` properties that server provides
|
|
280
|
+
- Only call methods that client implements
|
|
281
|
+
- Use correct Angular directives and bindings
|
|
282
|
+
|
|
283
|
+
**Critical Communication Points:**
|
|
284
|
+
|
|
285
|
+
1. **Server → Client Data Flow**
|
|
286
|
+
- Server sets `data.property`
|
|
287
|
+
- Client receives via `c.data.property`
|
|
288
|
+
- HTML displays with `{{data.property}}`
|
|
289
|
+
|
|
290
|
+
2. **Client → Server Requests**
|
|
291
|
+
- Client sends `c.server.get({action: 'name'})`
|
|
292
|
+
- Server receives via `input.action`
|
|
293
|
+
- Server processes and returns updated `data`
|
|
294
|
+
|
|
295
|
+
3. **HTML → Client Method Calls**
|
|
296
|
+
- HTML has `ng-click="methodName()"`
|
|
297
|
+
- Client must have `$scope.methodName = function()`
|
|
298
|
+
- Method typically calls server with `c.server.get()`
|
|
299
|
+
|
|
300
|
+
**Common Failures to Avoid:**
|
|
301
|
+
- Action name mismatches between client and server
|
|
302
|
+
- Method name mismatches between HTML and client
|
|
303
|
+
- Property name mismatches between server and HTML
|
|
304
|
+
- Missing handlers for client requests
|
|
305
|
+
- Orphaned data properties or methods
|
|
306
|
+
|
|
307
|
+
**Coherence Validation Checklist:**
|
|
308
|
+
- [ ] Every `data.property` in server is used in HTML/client
|
|
309
|
+
- [ ] Every `ng-click` in HTML has matching `$scope.method` in client
|
|
310
|
+
- [ ] Every `c.server.get({action})` in client has matching `if(input.action)` in server
|
|
311
|
+
- [ ] Data flows correctly: Server → HTML → Client → Server
|
|
312
|
+
- [ ] No orphaned methods or unused data properties
|
|
313
|
+
|
|
314
|
+
### Rule 5: Evidence-Based Debugging
|
|
315
|
+
|
|
316
|
+
Follow this systematic approach for all debugging:
|
|
317
|
+
|
|
318
|
+
1. **Reproduce** - Run the exact failing code
|
|
319
|
+
2. **Inventory** - List all dependencies
|
|
320
|
+
3. **Verify** - Test each dependency exists
|
|
321
|
+
4. **Fix** - Correct only confirmed issues
|
|
322
|
+
|
|
323
|
+
**Fix only:**
|
|
324
|
+
- ✅ Confirmed syntax errors
|
|
325
|
+
- ✅ Verified null references
|
|
326
|
+
- ✅ Missing dependencies (after verification)
|
|
327
|
+
- ✅ Real type mismatches
|
|
328
|
+
|
|
329
|
+
**Never change:**
|
|
330
|
+
- ❌ Unverified resources
|
|
331
|
+
- ❌ Configurations that "seem wrong"
|
|
332
|
+
- ❌ APIs you haven't tested
|
|
333
|
+
- ❌ Working code that could be "better"
|
|
334
|
+
|
|
335
|
+
## ServiceNow Development Standards
|
|
336
|
+
|
|
337
|
+
### Table Operations
|
|
338
|
+
- Always verify table existence before operations
|
|
339
|
+
- Use proper field types and references
|
|
340
|
+
- Check for ACLs and permissions
|
|
341
|
+
- Handle large datasets with pagination
|
|
342
|
+
|
|
343
|
+
### Script Development
|
|
344
|
+
- Use Script Includes for reusable code
|
|
345
|
+
- Implement proper error handling
|
|
346
|
+
- Add meaningful logging with gs.info/warn/error
|
|
347
|
+
- Test in scoped applications when applicable
|
|
348
|
+
|
|
349
|
+
### Widget Development
|
|
350
|
+
- Ensure HTML/Client/Server coherence
|
|
351
|
+
- Use Angular providers correctly
|
|
352
|
+
- Implement proper data binding
|
|
353
|
+
- Test across different themes and portals
|
|
354
|
+
|
|
355
|
+
### Flow Development
|
|
356
|
+
- Use proper trigger conditions
|
|
357
|
+
- Implement error handling paths
|
|
358
|
+
- Add appropriate logging actions
|
|
359
|
+
- Test with various data scenarios
|
|
360
|
+
|
|
361
|
+
## MCP Server Capabilities
|
|
362
|
+
|
|
363
|
+
Snow-Flow includes 18 specialized MCP servers, each providing comprehensive ServiceNow capabilities:
|
|
364
|
+
|
|
365
|
+
### 1. ServiceNow Deployment Server
|
|
366
|
+
**Purpose:** Widget and artifact deployment with coherence validation
|
|
367
|
+
|
|
368
|
+
**Key Tools:**
|
|
369
|
+
- `snow_deploy_widget` - Deploy widgets with HTML/Client/Server validation
|
|
370
|
+
- `snow_deploy_portal_page` - Deploy portal pages
|
|
371
|
+
- `snow_deploy_flow` - Deploy Flow Designer flows
|
|
372
|
+
- `snow_create_update_set` - Create update sets
|
|
373
|
+
- `snow_validate_deployment` - Validate deployed artifacts
|
|
374
|
+
- `snow_rollback_deployment` - Rollback failed deployments
|
|
375
|
+
|
|
376
|
+
**Special Features:**
|
|
377
|
+
- Automatic widget coherence validation
|
|
378
|
+
- Data flow contract verification
|
|
379
|
+
- Method implementation checking
|
|
380
|
+
- CSS class validation
|
|
381
|
+
|
|
382
|
+
### 2. ServiceNow Operations Server
|
|
383
|
+
**Purpose:** Core ServiceNow operations and queries
|
|
384
|
+
|
|
385
|
+
**Key Tools:**
|
|
386
|
+
- `snow_query_table` - Universal table querying with pagination
|
|
387
|
+
- `snow_create_incident` - Create and manage incidents
|
|
388
|
+
- `snow_update_record` - Update any table record
|
|
389
|
+
- `snow_delete_record` - Delete records with validation
|
|
390
|
+
- `snow_discover_table_fields` - Discover table schema
|
|
391
|
+
- `snow_cmdb_search` - Search Configuration Management Database
|
|
392
|
+
|
|
393
|
+
**Features:**
|
|
394
|
+
- Full CRUD operations on any table
|
|
395
|
+
- Advanced query capabilities
|
|
396
|
+
- Field discovery and validation
|
|
397
|
+
- Relationship navigation
|
|
398
|
+
|
|
399
|
+
### 3. ServiceNow Automation Server
|
|
400
|
+
**Purpose:** Script execution and automation
|
|
401
|
+
|
|
402
|
+
**Key Tools:**
|
|
403
|
+
- `snow_execute_script_with_output` - Execute scripts with output capture
|
|
404
|
+
- `snow_get_script_output` - Retrieve script execution history
|
|
405
|
+
- `snow_execute_script_sync` - Synchronous script execution
|
|
406
|
+
- `snow_get_logs` - Access system logs
|
|
407
|
+
- `snow_test_rest_connection` - Test REST integrations
|
|
408
|
+
- `snow_trace_execution` - Trace script execution
|
|
409
|
+
- `snow_schedule_job` - Create scheduled jobs
|
|
410
|
+
- `snow_create_event` - Trigger system events
|
|
411
|
+
|
|
412
|
+
**Features:**
|
|
413
|
+
- Full output capture (gs.print/info/warn/error)
|
|
414
|
+
- Execution history tracking
|
|
415
|
+
- System log access
|
|
416
|
+
- REST message testing
|
|
417
|
+
- Performance tracing
|
|
418
|
+
|
|
419
|
+
### 4. ServiceNow Platform Development Server
|
|
420
|
+
**Purpose:** Platform development artifacts
|
|
421
|
+
|
|
422
|
+
**Key Tools:**
|
|
423
|
+
- `snow_create_script_include` - Create reusable scripts
|
|
424
|
+
- `snow_create_business_rule` - Create business rules
|
|
425
|
+
- `snow_create_client_script` - Create client-side scripts
|
|
426
|
+
- `snow_create_ui_policy` - Create UI policies
|
|
427
|
+
- `snow_create_ui_action` - Create UI actions
|
|
428
|
+
- `snow_create_ui_page` - Create UI pages
|
|
429
|
+
|
|
430
|
+
**Features:**
|
|
431
|
+
- Full artifact creation
|
|
432
|
+
- Proper scoping support
|
|
433
|
+
- Condition builder integration
|
|
434
|
+
- Script validation
|
|
435
|
+
|
|
436
|
+
### 5. ServiceNow Integration Server
|
|
437
|
+
**Purpose:** Integration and data management
|
|
438
|
+
|
|
439
|
+
**Key Tools:**
|
|
440
|
+
- `snow_create_rest_message` - Create REST integrations
|
|
441
|
+
- `snow_create_transform_map` - Create data transformation maps
|
|
442
|
+
- `snow_create_import_set` - Manage import sets
|
|
443
|
+
- `snow_test_web_service` - Test web services
|
|
444
|
+
- `snow_configure_email` - Configure email settings
|
|
445
|
+
|
|
446
|
+
**Features:**
|
|
447
|
+
- REST/SOAP integration
|
|
448
|
+
- Data transformation
|
|
449
|
+
- Import/Export capabilities
|
|
450
|
+
- Email configuration
|
|
451
|
+
|
|
452
|
+
### 6. ServiceNow System Properties Server
|
|
453
|
+
**Purpose:** System property management
|
|
454
|
+
|
|
455
|
+
**Key Tools:**
|
|
456
|
+
- `snow_property_get` - Retrieve property values
|
|
457
|
+
- `snow_property_set` - Set property values
|
|
458
|
+
- `snow_property_list` - List properties by pattern
|
|
459
|
+
- `snow_property_delete` - Remove properties
|
|
460
|
+
- `snow_property_bulk_update` - Bulk operations
|
|
461
|
+
- `snow_property_export` - Export to JSON
|
|
462
|
+
- `snow_property_import` - Import from JSON
|
|
463
|
+
|
|
464
|
+
**Features:**
|
|
465
|
+
- Full CRUD on sys_properties
|
|
466
|
+
- Bulk operations
|
|
467
|
+
- Import/Export capabilities
|
|
468
|
+
- Property validation
|
|
469
|
+
|
|
470
|
+
### 7. ServiceNow Update Set Server
|
|
471
|
+
**Purpose:** Change management and deployment
|
|
472
|
+
|
|
473
|
+
**Key Tools:**
|
|
474
|
+
- `snow_create_update_set` - Create new update sets
|
|
475
|
+
- `snow_switch_update_set` - Switch active update set
|
|
476
|
+
- `snow_complete_update_set` - Mark as complete
|
|
477
|
+
- `snow_preview_update_set` - Preview changes
|
|
478
|
+
- `snow_export_update_set` - Export as XML
|
|
479
|
+
|
|
480
|
+
**Features:**
|
|
481
|
+
- Full update set lifecycle
|
|
482
|
+
- Change tracking
|
|
483
|
+
- XML export/import
|
|
484
|
+
- Conflict detection
|
|
485
|
+
|
|
486
|
+
### 8. ServiceNow Development Assistant Server
|
|
487
|
+
**Purpose:** Code generation and best practices
|
|
488
|
+
|
|
489
|
+
**Key Tools:**
|
|
490
|
+
- `snow_generate_code` - Generate ServiceNow code
|
|
491
|
+
- `snow_suggest_pattern` - Suggest design patterns
|
|
492
|
+
- `snow_review_code` - Code review and analysis
|
|
493
|
+
- `snow_optimize_performance` - Performance recommendations
|
|
494
|
+
|
|
495
|
+
**Features:**
|
|
496
|
+
- Pattern-based code generation
|
|
497
|
+
- Best practice enforcement
|
|
498
|
+
- Performance optimization
|
|
499
|
+
- Security review
|
|
500
|
+
|
|
501
|
+
### 9. ServiceNow Security & Compliance Server
|
|
502
|
+
**Purpose:** Security and compliance management
|
|
503
|
+
|
|
504
|
+
**Key Tools:**
|
|
505
|
+
- `snow_create_security_policy` - Create security policies
|
|
506
|
+
- `snow_audit_compliance` - Compliance auditing
|
|
507
|
+
- `snow_scan_vulnerabilities` - Vulnerability scanning
|
|
508
|
+
- `snow_assess_risk` - Risk assessment
|
|
509
|
+
- `snow_review_access_control` - ACL review
|
|
510
|
+
|
|
511
|
+
**Features:**
|
|
512
|
+
- SOX/GDPR/HIPAA compliance
|
|
513
|
+
- Security policy management
|
|
514
|
+
- Vulnerability assessment
|
|
515
|
+
- Access control validation
|
|
516
|
+
|
|
517
|
+
### 10. ServiceNow Reporting & Analytics Server
|
|
518
|
+
**Purpose:** Reporting and data visualization
|
|
519
|
+
|
|
520
|
+
**Key Tools:**
|
|
521
|
+
- `snow_create_report` - Create reports
|
|
522
|
+
- `snow_create_dashboard` - Create dashboards
|
|
523
|
+
- `snow_define_kpi` - Define KPIs
|
|
524
|
+
- `snow_schedule_report` - Schedule report delivery
|
|
525
|
+
- `snow_analyze_data_quality` - Data quality analysis
|
|
526
|
+
|
|
527
|
+
**Features:**
|
|
528
|
+
- Advanced reporting
|
|
529
|
+
- Dashboard creation
|
|
530
|
+
- KPI management
|
|
531
|
+
- Scheduled delivery
|
|
532
|
+
|
|
533
|
+
### 11. ServiceNow Machine Learning Server
|
|
534
|
+
**Purpose:** AI/ML capabilities
|
|
535
|
+
|
|
536
|
+
**Key Tools:**
|
|
537
|
+
- `snow_train_classifier` - Train incident classifier
|
|
538
|
+
- `snow_predict_change_risk` - Predict change risks
|
|
539
|
+
- `snow_detect_anomalies` - Anomaly detection
|
|
540
|
+
- `snow_forecast_incidents` - Incident forecasting
|
|
541
|
+
- `snow_optimize_process` - Process optimization
|
|
542
|
+
|
|
543
|
+
**Features:**
|
|
544
|
+
- Predictive analytics
|
|
545
|
+
- Pattern recognition
|
|
546
|
+
- Anomaly detection
|
|
547
|
+
- Process optimization
|
|
548
|
+
|
|
549
|
+
### 12. ServiceNow Knowledge & Catalog Server
|
|
550
|
+
**Purpose:** Knowledge base and service catalog management
|
|
551
|
+
|
|
552
|
+
**Key Tools:**
|
|
553
|
+
- `snow_create_knowledge_article` - Create knowledge articles
|
|
554
|
+
- `snow_search_knowledge` - Search knowledge base
|
|
555
|
+
- `snow_create_catalog_item` - Create catalog items
|
|
556
|
+
- `snow_create_catalog_variable` - Create catalog variables
|
|
557
|
+
- `snow_create_catalog_ui_policy` - Create UI policies
|
|
558
|
+
- `snow_order_catalog_item` - Order catalog items
|
|
559
|
+
- `snow_discover_catalogs` - Discover available catalogs
|
|
560
|
+
|
|
561
|
+
**Features:**
|
|
562
|
+
- Knowledge article management
|
|
563
|
+
- Service catalog configuration
|
|
564
|
+
- Catalog item ordering
|
|
565
|
+
- Variable and policy management
|
|
566
|
+
|
|
567
|
+
### 13. ServiceNow Change, Virtual Agent & PA Server
|
|
568
|
+
**Purpose:** Change management, Virtual Agent, and Performance Analytics
|
|
569
|
+
|
|
570
|
+
**Key Tools:**
|
|
571
|
+
- `snow_create_change_request` - Create change requests
|
|
572
|
+
- `snow_schedule_cab_meeting` - Schedule CAB meetings
|
|
573
|
+
- `snow_create_va_topic` - Create Virtual Agent topics
|
|
574
|
+
- `snow_send_va_message` - Send VA messages
|
|
575
|
+
- `snow_create_pa_indicator` - Create PA indicators
|
|
576
|
+
- `snow_create_pa_widget` - Create PA widgets
|
|
577
|
+
- `snow_get_pa_scores` - Get performance scores
|
|
578
|
+
|
|
579
|
+
**Features:**
|
|
580
|
+
- Change management workflows
|
|
581
|
+
- Virtual Agent configuration
|
|
582
|
+
- Performance Analytics setup
|
|
583
|
+
- CAB meeting management
|
|
584
|
+
|
|
585
|
+
### 14. ServiceNow Flow, Workspace & Mobile Server
|
|
586
|
+
**Purpose:** Flow Designer, Workspace configuration, and Mobile app management
|
|
587
|
+
|
|
588
|
+
**Key Tools:**
|
|
589
|
+
- `snow_list_flows` - List and discover Flow Designer flows
|
|
590
|
+
- `snow_execute_flow` - Execute existing flows programmatically
|
|
591
|
+
- `snow_get_flow_execution_status` - Monitor flow execution status
|
|
592
|
+
- `snow_get_flow_execution_history` - View flow execution history
|
|
593
|
+
- `snow_get_flow_details` - Get detailed flow configuration
|
|
594
|
+
- `snow_import_flow_from_xml` - Import flows from XML (only programmatic creation method)
|
|
595
|
+
- `snow_create_workspace` - Create workspaces
|
|
596
|
+
- `snow_configure_mobile_app` - Configure mobile app
|
|
597
|
+
- `snow_send_push_notification` - Send push notifications
|
|
598
|
+
- `snow_configure_offline_sync` - Configure offline sync
|
|
599
|
+
|
|
600
|
+
**Important:** Flow creation is only supported through Flow Designer UI, not programmatically
|
|
601
|
+
|
|
602
|
+
**Features:**
|
|
603
|
+
- Flow Designer automation
|
|
604
|
+
- Workspace configuration
|
|
605
|
+
- Mobile app management
|
|
606
|
+
- Push notification system
|
|
607
|
+
|
|
608
|
+
### 15. ServiceNow CMDB, Event, HR, CSM & DevOps Server
|
|
609
|
+
**Purpose:** CMDB management, Event processing, HR services, Customer Service, and DevOps
|
|
610
|
+
|
|
611
|
+
**Key Tools:**
|
|
612
|
+
- `snow_create_ci` - Create Configuration Items
|
|
613
|
+
- `snow_create_ci_relationship` - Create CI relationships
|
|
614
|
+
- `snow_run_discovery` - Run discovery
|
|
615
|
+
- `snow_create_event` - Create events
|
|
616
|
+
- `snow_create_hr_case` - Create HR cases
|
|
617
|
+
- `snow_employee_onboarding` - Employee onboarding
|
|
618
|
+
- `snow_create_customer_case` - Create customer cases
|
|
619
|
+
- `snow_create_devops_pipeline` - Create DevOps pipelines
|
|
620
|
+
|
|
621
|
+
**Features:**
|
|
622
|
+
- CMDB management
|
|
623
|
+
- Event correlation
|
|
624
|
+
- HR case management
|
|
625
|
+
- Customer service management
|
|
626
|
+
- DevOps pipeline integration
|
|
627
|
+
|
|
628
|
+
### 16. ServiceNow Advanced Features Server
|
|
629
|
+
**Purpose:** Advanced capabilities for optimization and analysis
|
|
630
|
+
|
|
631
|
+
**Key Tools:**
|
|
632
|
+
- `snow_batch_api` - Batch API operations (80% API reduction)
|
|
633
|
+
- `snow_get_table_relationships` - Analyze table relationships
|
|
634
|
+
- `snow_analyze_query` - Query optimization
|
|
635
|
+
- `snow_detect_code_patterns` - Code pattern detection
|
|
636
|
+
- `snow_discover_process` - Process discovery
|
|
637
|
+
- `snow_analyze_workflow_execution` - Workflow analysis
|
|
638
|
+
- `snow_generate_documentation` - Auto-documentation
|
|
639
|
+
|
|
640
|
+
**Features:**
|
|
641
|
+
- Batch operations for performance
|
|
642
|
+
- Advanced analytics
|
|
643
|
+
- Process mining
|
|
644
|
+
- Code optimization
|
|
645
|
+
- Automatic documentation
|
|
646
|
+
|
|
647
|
+
### 17. ServiceNow Local Development Server
|
|
648
|
+
**Purpose:** Bridge between ServiceNow artifacts and Claude Code's native development tools
|
|
649
|
+
|
|
650
|
+
**Key Tools:**
|
|
651
|
+
- `snow_pull_artifact` - Pull any ServiceNow artifact to local files
|
|
652
|
+
- `snow_push_artifact` - Push local changes back with validation
|
|
653
|
+
- `snow_validate_artifact_coherence` - Validate artifact relationships
|
|
654
|
+
- `snow_list_supported_artifacts` - List all supported artifact types
|
|
655
|
+
- `snow_sync_status` - Check sync status of local artifacts
|
|
656
|
+
- `snow_sync_cleanup` - Clean up local files after sync
|
|
657
|
+
- `snow_convert_to_es5` - Convert modern JavaScript to ES5
|
|
658
|
+
|
|
659
|
+
**Features:**
|
|
660
|
+
- Supports 12+ artifact types dynamically
|
|
661
|
+
- Smart field chunking for large artifacts
|
|
662
|
+
- ES5 validation for server-side scripts
|
|
663
|
+
- Coherence validation for widgets
|
|
664
|
+
- Full Claude Code native tool integration
|
|
665
|
+
|
|
666
|
+
**Supported Artifact Types:**
|
|
667
|
+
- Service Portal Widgets (`sp_widget`)
|
|
668
|
+
- Flow Designer Flows (`sys_hub_flow`)
|
|
669
|
+
- Script Includes (`sys_script_include`)
|
|
670
|
+
- Business Rules (`sys_script`)
|
|
671
|
+
- UI Pages (`sys_ui_page`)
|
|
672
|
+
- Client Scripts (`sys_script_client`)
|
|
673
|
+
- UI Policies (`sys_ui_policy`)
|
|
674
|
+
- REST Messages (`sys_rest_message`)
|
|
675
|
+
- Transform Maps (`sys_transform_map`)
|
|
676
|
+
- Scheduled Jobs (`sysauto_script`)
|
|
677
|
+
- Fix Scripts (`sys_script_fix`)
|
|
678
|
+
|
|
679
|
+
### 18. Snow-Flow Orchestration Server
|
|
680
|
+
**Purpose:** Multi-agent coordination and task management
|
|
681
|
+
|
|
682
|
+
**Key Tools:**
|
|
683
|
+
- `snow_swarm_init` - Initialize agent swarms
|
|
684
|
+
- `snow_agent_spawn` - Create specialized agents
|
|
685
|
+
- `snow_task_orchestrate` - Orchestrate complex tasks
|
|
686
|
+
- `snow_memory_store` - Persistent memory storage
|
|
687
|
+
- `snow_neural_train` - Train neural networks
|
|
688
|
+
- `snow_performance_analyze` - Performance analysis
|
|
689
|
+
|
|
690
|
+
**Features:**
|
|
691
|
+
- Multi-agent coordination
|
|
692
|
+
- Task orchestration
|
|
693
|
+
- Neural network training (TensorFlow.js)
|
|
694
|
+
- Memory management
|
|
695
|
+
- Performance monitoring
|
|
696
|
+
|
|
697
|
+
## Local Development with Artifact Sync
|
|
698
|
+
|
|
699
|
+
### Dynamic Artifact Synchronization
|
|
700
|
+
|
|
701
|
+
The Local Development Server enables editing ServiceNow artifacts using Claude Code's native file tools. This creates a powerful development bridge between ServiceNow and local development environments.
|
|
702
|
+
|
|
703
|
+
**Workflow:**
|
|
704
|
+
|
|
705
|
+
1. **Pull Artifact to Local Files**
|
|
706
|
+
```javascript
|
|
707
|
+
// Auto-detect artifact type
|
|
708
|
+
snow_pull_artifact({ sys_id: 'any_sys_id' });
|
|
709
|
+
|
|
710
|
+
// Or specify table for faster pull
|
|
711
|
+
snow_pull_artifact({
|
|
712
|
+
sys_id: 'widget_sys_id',
|
|
713
|
+
table: 'sp_widget'
|
|
714
|
+
});
|
|
715
|
+
```
|
|
716
|
+
|
|
717
|
+
2. **Edit with Claude Code Native Tools**
|
|
718
|
+
- Full search capabilities across files
|
|
719
|
+
- Multi-file editing and refactoring
|
|
720
|
+
- Syntax highlighting and validation
|
|
721
|
+
- Git-like diff viewing
|
|
722
|
+
- Go-to-definition and references
|
|
723
|
+
|
|
724
|
+
3. **Validate Coherence**
|
|
725
|
+
```javascript
|
|
726
|
+
// Check artifact relationships
|
|
727
|
+
snow_validate_artifact_coherence({
|
|
728
|
+
sys_id: 'artifact_sys_id'
|
|
729
|
+
});
|
|
730
|
+
```
|
|
731
|
+
|
|
732
|
+
4. **Push Changes Back**
|
|
733
|
+
```javascript
|
|
734
|
+
// Push with automatic validation
|
|
735
|
+
snow_push_artifact({ sys_id: 'artifact_sys_id' });
|
|
736
|
+
|
|
737
|
+
// Force push despite warnings
|
|
738
|
+
snow_push_artifact({
|
|
739
|
+
sys_id: 'artifact_sys_id',
|
|
740
|
+
force: true
|
|
741
|
+
});
|
|
742
|
+
```
|
|
743
|
+
|
|
744
|
+
5. **Clean Up**
|
|
745
|
+
```javascript
|
|
746
|
+
// Remove local files after sync
|
|
747
|
+
snow_sync_cleanup({ sys_id: 'artifact_sys_id' });
|
|
748
|
+
```
|
|
749
|
+
|
|
750
|
+
**Artifact Registry:**
|
|
751
|
+
|
|
752
|
+
Each artifact type is configured with:
|
|
753
|
+
- Field mappings to local files
|
|
754
|
+
- Context-aware wrappers for better editing
|
|
755
|
+
- ES5 validation flags for server scripts
|
|
756
|
+
- Coherence rules for interconnected fields
|
|
757
|
+
- Preprocessors/postprocessors for data transformation
|
|
758
|
+
|
|
759
|
+
**File Structure Example:**
|
|
760
|
+
```
|
|
761
|
+
/tmp/snow-flow-artifacts/
|
|
762
|
+
├── widgets/
|
|
763
|
+
│ └── my_widget/
|
|
764
|
+
│ ├── my_widget.html # Template
|
|
765
|
+
│ ├── my_widget.server.js # Server script (ES5)
|
|
766
|
+
│ ├── my_widget.client.js # Client script
|
|
767
|
+
│ ├── my_widget.css # Styles
|
|
768
|
+
│ ├── my_widget.config.json # Configuration
|
|
769
|
+
│ └── README.md # Context & instructions
|
|
770
|
+
├── script_includes/
|
|
771
|
+
│ └── MyScriptInclude/
|
|
772
|
+
│ ├── MyScriptInclude.js # Script
|
|
773
|
+
│ └── MyScriptInclude.docs.md # Documentation
|
|
774
|
+
└── business_rules/
|
|
775
|
+
└── my_rule/
|
|
776
|
+
├── my_rule.js # Rule script
|
|
777
|
+
└── my_rule.condition.js # Condition
|
|
778
|
+
```
|
|
779
|
+
|
|
780
|
+
**Benefits:**
|
|
781
|
+
- Use your favorite editor features
|
|
782
|
+
- Full search and replace capabilities
|
|
783
|
+
- Version control integration
|
|
784
|
+
- Bulk operations across artifacts
|
|
785
|
+
- Offline development capability
|
|
786
|
+
- Advanced refactoring tools
|
|
787
|
+
|
|
788
|
+
## Debugging Best Practices
|
|
789
|
+
|
|
790
|
+
### Systematic Debugging Protocol
|
|
791
|
+
|
|
792
|
+
1. **Reproduce the Issue**
|
|
793
|
+
```javascript
|
|
794
|
+
// Always use ES5 and test exact code
|
|
795
|
+
const result = await snow_execute_script_with_output({
|
|
796
|
+
script: `/* Exact failing code in ES5 */`
|
|
797
|
+
});
|
|
798
|
+
```
|
|
799
|
+
|
|
800
|
+
2. **Verify Dependencies**
|
|
801
|
+
- Check all referenced tables exist
|
|
802
|
+
- Verify all properties are set
|
|
803
|
+
- Confirm all fields are present
|
|
804
|
+
- Test all integrations work
|
|
805
|
+
|
|
806
|
+
3. **Test in Context**
|
|
807
|
+
- Use same scope and variables
|
|
808
|
+
- Include same imports
|
|
809
|
+
- Test with same data
|
|
810
|
+
|
|
811
|
+
4. **Apply Evidence-Based Fixes**
|
|
812
|
+
- Fix only confirmed issues
|
|
813
|
+
- Document why changes were made
|
|
814
|
+
- Test fixes thoroughly
|
|
815
|
+
|
|
816
|
+
### Common Verification Patterns
|
|
817
|
+
|
|
818
|
+
**Table Verification:**
|
|
819
|
+
```javascript
|
|
820
|
+
var table = new GlideRecord('table_name');
|
|
821
|
+
gs.info('Table exists: ' + table.isValid());
|
|
822
|
+
```
|
|
823
|
+
|
|
824
|
+
**Property Verification:**
|
|
825
|
+
```javascript
|
|
826
|
+
var prop = gs.getProperty('property.name');
|
|
827
|
+
gs.info('Property value: ' + (prop || 'NOT SET'));
|
|
828
|
+
```
|
|
829
|
+
|
|
830
|
+
**Field Verification:**
|
|
831
|
+
```javascript
|
|
832
|
+
var gr = new GlideRecord('table');
|
|
833
|
+
var element = gr.getElement('field_name');
|
|
834
|
+
gs.info('Field exists: ' + (element ? 'Yes' : 'No'));
|
|
835
|
+
```
|
|
836
|
+
|
|
837
|
+
## Command Reference
|
|
838
|
+
|
|
839
|
+
### Core Commands
|
|
840
|
+
- `./snow-flow start` - Start orchestration system
|
|
841
|
+
- `./snow-flow status` - System status
|
|
842
|
+
- `./snow-flow monitor` - Real-time monitoring
|
|
843
|
+
|
|
844
|
+
### Agent Management
|
|
845
|
+
- `./snow-flow agent spawn <type>` - Create agents
|
|
846
|
+
- `./snow-flow agent list` - List active agents
|
|
847
|
+
|
|
848
|
+
### Task Management
|
|
849
|
+
- `./snow-flow task create` - Create tasks
|
|
850
|
+
- `./snow-flow task list` - View task queue
|
|
851
|
+
|
|
852
|
+
### Memory Operations
|
|
853
|
+
- `./snow-flow memory store <key> <data>` - Store data
|
|
854
|
+
- `./snow-flow memory get <key>` - Retrieve data
|
|
855
|
+
- `./snow-flow memory list` - List all keys
|
|
856
|
+
|
|
857
|
+
### SPARC Modes
|
|
858
|
+
- `./snow-flow sparc "<task>"` - Orchestrator mode
|
|
859
|
+
- `./snow-flow sparc run <mode> "<task>"` - Specific mode
|
|
860
|
+
- `./snow-flow sparc tdd "<feature>"` - Test-driven development
|
|
861
|
+
|
|
862
|
+
### Swarm Coordination
|
|
863
|
+
- `./snow-flow swarm "<objective>"` - Multi-agent coordination
|
|
864
|
+
- Options: `--strategy`, `--mode`, `--parallel`, `--monitor`
|
|
865
|
+
|
|
866
|
+
## Workflow Guidelines
|
|
867
|
+
|
|
868
|
+
### Development Workflow
|
|
869
|
+
1. **Plan** - Use TodoWrite for task management
|
|
870
|
+
2. **Verify** - Check existing resources
|
|
871
|
+
3. **Develop** - Follow ES5 standards
|
|
872
|
+
4. **Test** - Use background scripts
|
|
873
|
+
5. **Deploy** - Use update sets
|
|
874
|
+
6. **Validate** - Verify deployment
|
|
875
|
+
|
|
876
|
+
### Testing Workflow
|
|
877
|
+
1. Run unit tests with background scripts
|
|
878
|
+
2. Test integrations with REST tools
|
|
879
|
+
3. Validate UI with widget coherence
|
|
880
|
+
4. Check performance with tracing
|
|
881
|
+
5. Review logs for errors
|
|
882
|
+
|
|
883
|
+
### Debugging Workflow
|
|
884
|
+
1. Reproduce issue exactly
|
|
885
|
+
2. Gather evidence with scripts
|
|
886
|
+
3. Verify all assumptions
|
|
887
|
+
4. Apply minimal fixes
|
|
888
|
+
5. Test thoroughly
|
|
889
|
+
6. Document changes
|
|
890
|
+
|
|
891
|
+
## Important Reminders
|
|
892
|
+
|
|
893
|
+
### Always Remember
|
|
894
|
+
- Every ServiceNow instance is unique
|
|
895
|
+
- Custom implementations exist that you don't know about
|
|
896
|
+
- Preview/beta features may be available
|
|
897
|
+
- Organization-specific configurations are common
|
|
898
|
+
- Test everything before making assumptions
|
|
899
|
+
|
|
900
|
+
### Never Assume
|
|
901
|
+
- That something doesn't exist without verification
|
|
902
|
+
- That configurations are wrong without testing
|
|
903
|
+
- That APIs aren't available without checking
|
|
904
|
+
- That code won't work without running it
|
|
905
|
+
- That you know better than existing implementations
|
|
906
|
+
|
|
907
|
+
### Golden Rules
|
|
908
|
+
1. **Verify First** - Test before declaring broken
|
|
909
|
+
2. **ES5 Only** - No modern JavaScript in ServiceNow
|
|
910
|
+
3. **Evidence-Based** - Make decisions on facts, not assumptions
|
|
911
|
+
4. **Minimal Changes** - Fix only what's broken
|
|
912
|
+
5. **Respect Context** - Understand why things exist as they do
|
|
913
|
+
|
|
914
|
+
## Conclusion
|
|
915
|
+
|
|
916
|
+
Snow-Flow is a powerful framework for ServiceNow development that emphasizes verification, testing, and evidence-based decision making. By following these guidelines and best practices, you ensure reliable, maintainable, and effective ServiceNow solutions.
|
|
917
|
+
|
|
918
|
+
Remember: Your job is to solve problems, not to judge implementations. Every environment has its reasons for existing configurations. Verify, test, and respect what you find.
|