🧩 ServiceNow – Guide Complet (Platform, ITSM, Dev & Ops)

“Now Platform” : les couches

[ UI Layer ]
- Forms / Lists / Workspaces
- Service Portal / UI Builder
- Notifications (email, push)

[ Workflow Layer ]
- Flow Designer / Approvals
- Business Rules / Script Actions
- SLA / Escalations / Tasks

[ Data Layer ]
- Tables + Dictionary
- CMDB (CIs + relations)
- Attachments, audit, history

[ Security & Governance ]
- Users / Groups / Roles (RBAC)
- ACL (field/table)
- Domain separation (selon usage)
- Audit, policies

[ Integration Layer ]
- REST / SOAP APIs
- Import Sets + Transform Maps
- IntegrationHub (connecteurs)
- MID Server (réseau privé)
            

Modules : lecture rapide

Image à insérer (branding) :

Placeholder : static/img/servicenow/now_platform_layers.png

Navigation : les 6 écrans que tu dois maîtriser

Mini-diagramme : UI côté client

Form (UI)
- UI Policy (low-code) : show/hide, mandatory, read-only
- Client Script (JS)   : onChange/onLoad/onSubmit
        │
        ▼
Server
- Business Rule : before/after, validations, side effects
- Flow Designer : orchestration, approvals, notifications
- ACL : droits d'accès effectifs
            

RBAC : Users / Groups / Roles

Le contrôle d’accès se fait via rôles (attribués directement ou via groupes) et via ACL (au niveau table / champ).

User  →  Groups  →  Roles  →  ACL (table/field)
            

Check “sécurité minimale” (projet)

• Créer un rôle x_myapp.user pour l’app
• Créer un rôle x_myapp.admin (admin app)
• Verrouiller tables custom via ACL (CRUD)
• Tester avec un user non-admin

ACL : table vs field

Image à insérer :

Placeholder : static/img/servicenow/rbac_acl_flow.png

Première mini-app (propre, “enterprise-ready”)

Objectif : faire une app “Request → Record → Flow → Notification”. Exemple : Demande d’accès (Access Request).

1. Créer une table x_ideo_access_request
2. Champs : requestor, system, justification, status, approver
3. UI : form + list + views
4. Flow : à la création → approval → status update → notif

Diagramme “mini-app”

User submits Form
    │
    ▼
Record created (x_ideo_access_request)
    │
    ▼
Flow Designer
- Create approval task
- Wait for decision
- Update status
- Notify requestor
            

Flow Designer vs Business Rules : qui fait quoi ?

Anti-pattern “monstre”

20 Business Rules déclenchées sur incident (before+after), plus 5 flows qui modifient le même champ. Résultat : comportements imprévisibles.

Diagramme “ordre de traitement” (simplifié)

Client submits record
    │
    ▼
Server "Before" Business Rules
    │
    ▼
Database write (insert/update)
    │
    ▼
Server "After" Business Rules
    │
    ▼
Flows / Notifications / SLA recalculations
            

Image à insérer :

Placeholder : static/img/servicenow/automation_order.png

UI : Lists, Forms, Workspaces

• List : filtre, group by, export, vues
• Form : sections, related lists, policies, scripts
• Workspace : UI agent moderne (productivité)
• Portal : expérience self-service (catalog)

Tableau : outils UI

UX “safe” : ce qu’un senior fait

• UX côté client → confort, pas sécurité.
• Validation côté serveur → règle métier + audit.
• Tester avec rôle user réel (pas admin).
• Éviter les scripts lourds “onChange” (latence).

MID Server : le pont vers le réseau privé

Quand l’instance cloud doit parler à des systèmes derrière firewall (AD, DB on-prem, outils internes), on déploie un MID Server sur un serveur interne.

ServiceNow Cloud Instance
   │   (HTTPS outbound)
   ▼
MID Server (On-Prem)
   │   (LDAP/JDBC/SSH/SNMP/HTTP...)
   ▼
Internal Systems (AD, DB, CM tools, APIs)
            

Pourquoi c’est critique

• Sécurité : pas d’ouverture inbound vers le SI
• Intégrations : discovery, imports, orchestrations
• Ops : monitoring / events / CMDB mapping

Image à insérer :

Placeholder : static/img/servicenow/mid_server_network.png

SLA : idée générale

Un SLA est un “contrat de temps” : réponse / résolution. Il s’arrête / se met en pause selon état, horaires, exceptions.

SLA = timer + conditions (start/stop/pause)
- start: state = New
- pause: waiting for user
- stop : state = Resolved
            

Escalations : l’automatisation utile

• Notifier avant violation (ex: 80%)
• Reassign si groupe saturé
• Créer une tâche “major incident”

Construire une app : pattern minimal

Diagramme “app package”

Application (scope x_ideo_myapp)
- Tables
- UI (forms, lists, views)
- Flows / Rules
- ACL / Roles
- Script Includes
- REST APIs
            

Image à insérer :

Placeholder : static/img/servicenow/app_scope_package.png

REST (exemple conceptuel)

ServiceNow expose des APIs REST pour lire/écrire des records et pour intégrer des systèmes externes. Ci-dessous : exemple “créer un incident”.

POST /api/now/table/incident
Content-Type: application/json
Authorization: Bearer <token>

{
  "short_description": "VPN down for user",
  "caller_id": "sys_id_user",
  "category": "network",
  "priority": "2"
}
            

Réponse attendue

{
  "result": {
    "sys_id": "...",
    "number": "INC0012345",
    "state": "1",
    "opened_at": "..."
  }
}
            

Import Sets : principe

Source (CSV/API/DB)
   │
   ▼
Staging Table (Import Set)
   │
   ▼
Transform Map (mapping + scripts)
   │
   ▼
Target Table(s)
            

Bonnes pratiques

• Staging “append-only” (audit)
• Déduplication explicite (clé logique)
• Transform scripts versionnés
• Dashboard qualité (erreurs mapping)