Mini Project Assignment
Incident Management Application – Advanced Logic & Scripting Lab
Focus Areas: Business Rules, Fixed Scripts, Background Scripts, UI Policies and ACLs
Scenario
Your team is enhancing the standard Incident Management application for an enterprise support organization. The
objective is to build stronger validation, controlled access, user guidance, and operational repair utilities so that
incidents are created correctly, routed properly, and governed securely.
Project Type Scenario-based implementation assignment
Primary Table Incident [incident]
Target Skill Level Intern progressing toward implementation readiness
Working solution with scripts, ACLs, test evidence and
Expected Outcome
explanation of logic
Incident Management Advanced Mini Project Assignment
1. Project Objectives
• Strengthen understanding of server-side and client-side logic on the Incident table.
• Test logical thinking through rule sequencing, condition design, and exception handling.
• Implement security controls with table-level and field-level ACLs based on role and assignment logic.
• Use background scripts and fixed scripts responsibly for validation, correction and data repair.
• Demonstrate not only completion, but also why each logic component was designed in that way.
2. Business Scenario
Company context: The support desk receives incidents from multiple business units. Many incidents are logged with
incomplete details, incorrect urgency, or unauthorized updates. Managers also want controlled visibility over
sensitive incidents and a repair mechanism for old records where priority and categorization were not maintained
properly.
You must enhance the Incident application to satisfy the following business expectations:
• Users should be guided on the form based on the type and state of the incident.
• Critical fields must be validated before save through business rules.
• Sensitive incidents should be protected through ACLs.
• Support teams should be able to run data-fix utilities in a controlled manner.
• Developers should be able to validate logic quickly using a background script.
3. Functional Scope to Build
Module What to Build Suggested Technical Object Validation Goal
Hide/show or make fields
Incident guidance mandatory depending on UI Policies User gets guided before save
impact, category and state
Block invalid inserts/updates
Incorrect data should not
Save-time validation and auto-set values where Business Rules
persist
needed
Restrict access to confidential
Security control ACLs Least privilege enforced
incidents and selected fields
Check records and print
Mass validation utility result logs without manual Background Script Quick logical verification
form opening
Correct historical bad data in Production-safe one-time
Repair utility Fixed Script
a controlled way correction
4. Detailed Implementation Tasks
Task A – UI Policy implementation
• When Category = Software, make the Configuration Item field mandatory.
Incident Management Advanced Mini Project Assignment
• When Impact = 1 - High, display a justification field or use Work notes as mandatory through UI policy logic
guidance.
• When State = Resolved, make Resolution code and Resolution notes mandatory.
• When Contact type = Self-service, make Short description and Description prominently required and hide any
internal-only helper field from normal users.
• Add at least one reverse-if-false behavior and explain why it is needed.
Task B – Business Rule implementation
Create multiple business rules on Incident. At minimum include the following patterns:
• Before Insert/Update rule: If Impact and Urgency are both High, ensure Priority becomes Critical; do not depend
only on client-side logic.
• Before Update rule: Prevent incident closure when Resolution code is empty or Description has not been
meaningfully populated for the record lifecycle.
• After Insert or After Update rule: When Priority becomes Critical, add a work note entry or event/log message
indicating escalation logic was triggered.
• Display Business Rule: Send a server-side message or scratchpad-style information that can help explain restricted-
state behavior on form load.
• Use conditions properly. Do not run rules on every save without reason.
Task C – ACL implementation
• Create a table-level read ACL so only users with an elevated support role can read incidents marked as Confidential
= true.
• Create a write ACL so only the Assigned to user, Assignment group manager, or admin can update confidential
incidents after assignment.
• Create a field-level ACL on a sensitive field such as Close notes, Resolution notes or a custom Confidential reason
field.
• Document whether your ACL uses role check only, script only, or a combination of role + script, and justify the
design.
• Explain the evaluation order and where deny-by-default is helping the design.
Task D – Background script
• Write a background script that retrieves incidents created in the last 30 days with High impact or High urgency.
• Print incident number, caller, assignment group, state and priority in logs.
• Add logical validation in the script to identify incidents where Priority does not match expected Impact/Urgency
combination.
• At the end, print a summary count: total records checked, valid records, mismatched records.
Task E – Fixed script
• Create a one-time fix script to repair historical incidents where Priority is blank, State is Resolved but Resolution
code is empty, or Category = Software while Configuration Item is empty.
• Do not blindly update all records. Query only the required subset.
• Use logging to show before/after behavior and final count of corrected records.
• Your fix script should be idempotent as far as possible, meaning re-running it should not create unnecessary
damage or duplicate comments/work notes.
Incident Management Advanced Mini Project Assignment
5. Recommended Technical Design
Area Recommendation Why it matters
Use only for user guidance and client- Improves usability but should not be
UI Policy
side behavior trusted for security or final validation
Use before rules for
Business Rule validation/defaulting and after rules for Protects data integrity on the server
logging/escalation actions
Use least-privilege access with tight Secures records and fields regardless of
ACL
condition/script logic UI path
Use for investigation, reporting or quick
Background Script Fast testing of logic and data quality
validation in lower environments
Use for controlled historical data repair Supports safe correction of bad existing
Fixed Script
with scoped query and clear logging data
6. Sample Logic Expectations
These are expected behaviors to test in your implementation:
Test Situation Expected Result Where validated Pass/Fail Evidence
User sets State to Resolved Record must not save or must Before Business Rule / UI
Screenshot + explanation
without Resolution code be blocked with message Policy
User opens confidential
Record or field should not be
incident without required ACL Role test evidence
visible/editable
role
Incident is P1-like by impact
System auto-corrects or flags Business Rule / Background
and urgency but priority Script log or record proof
mismatch Script
remains low
Resolved software incident UI guidance plus server
UI Policy + Business Rule Attempted save evidence
has no CI validation should catch it
Fix script corrects only
Historical bad records exist Fixed Script Before/after log evidence
targeted records
Incident Management Advanced Mini Project Assignment
7. Suggested Script Skeleton Ideas
These are guide patterns only. Learners should adapt, improve and explain them.
Before Business Rule pattern
if ([Link] == '1' && [Link] == '1') {
[Link] = '1';
}
if ([Link]('6') && [Link](current.close_code)) {
[Link]('Resolution code is mandatory before closure.');
[Link](true);
}
Background Script pattern
var gr = new GlideRecord('incident');
[Link]('sys_created_onRELATIVEGE@dayofweek@ago@30^ORimpact=1^ORurgency=1');
[Link]();
var total = 0, mismatch = 0;
while ([Link]()) {
total++;
var expectedCritical = ([Link] == 1 && [Link] == 1);
if (expectedCritical && [Link] != 1) {
mismatch++;
[Link]('Mismatch: ' + [Link]);
}
}
[Link]('Checked=' + total + ', mismatched=' + mismatch);
Fix Script pattern
var fix = new GlideRecord('incident');
[Link]('state=6^close_codeISEMPTY^ORcategory=software^cmdb_ciISEMPTY');
[Link]();
var updated = 0;
while ([Link]()) {
if ([Link] == 6 && [Link](fix.close_code)) {
fix.close_code = 'Solved (Permanently)';
}
if ([Link] == 'software' && [Link](fix.cmdb_ci)) {
// set fallback value only if approved by scenario
}
[Link]();
updated++;
}
[Link]('Total corrected=' + updated);
8. Submission Checklist
Item Expected from learner Reviewer check
Incident Management Advanced Mini Project Assignment
Configured and tested with reverse
UI Policies Yes / No
behavior
At least before + after/display style
Business Rules Yes / No
coverage
Table and field access validated with
ACLs Yes / No
different users/roles
Background Script Produces correct validation logs Yes / No
Repairs only targeted records with safe
Fixed Script Yes / No
query
Screenshots or stepwise validation notes
Test Evidence Yes / No
attached
Learner can explain why each logic
Explanation Yes / No
choice was made
9. Discussion Questions for Review
• Why should UI Policies not be treated as a security control?
• Why is server-side validation still required even when client-side behavior exists?
• What is the difference between a background script and a fixed script in practical governance terms?
• How would you avoid performance issues in ACL scripts and business rules?
• What could go wrong if a fix script is written without tight query conditions?
10. Expected Learning Outcome
By the end of this assignment, the learner should be able to design and defend implementation logic on the Incident
table, understand when to use client guidance versus server enforcement, secure data correctly using ACLs, and use
operational scripts for analysis and repair in a disciplined way.
Incident Management Advanced Mini Project Assignment