Learn IT with Shikha Blogs

Le problème le plus fréquent en production (et comment le résoudre) Vous soumettez un élément du catalogue. La demande est créée. Le RITM est créé. Mais… aucune tâche (SCTASK) n’apparaît. C’est l’un des problèmes les plus fréquents dans ServiceNow. Et dans la majorité des cas — le workflow existe bien. Le problème vient généralement de la configuration logique. Ce qui devrait normalement se passer Lorsqu’un utilisateur soumet un élément du catalogue : REQ → RITM → Workflow / Flow → SCTASK Si la SCTASK manque, le workflow ne s’est pas exécuté correctement. Cause n°1 — Workflow non attaché à l’élément du catalogue Erreur la plus courante. Le workflow est créé mais non associé. Vérifier Catalogue Item → Process Engine → Workflow / Flow Designer Vide = aucune tâche générée Cause n°2 — Conditions évaluées à faux Exemple : Département = IT Si l’utilisateur choisit RH → le workflow saute l’activité. Symptôme Workflow démarre puis s’arrête immédiatement. Cause n°3 — Mauvaise table dans Flo...

The Most Common Issue Developers Face (and How to Fix It) You submit a catalog item. The request is created. The RITM is created. But… no catalog tasks appear. This is one of the most frequent ServiceNow production issues. And surprisingly — the workflow is usually correct. The problem is usually hidden in configuration logic. What Should Normally Happen When a user submits a catalog item: REQ → RITM → Workflow/Flow → SCTASK If SCTASK is missing, the workflow never executed properly. Root Cause #1 — Workflow Not Attached to Catalog Item Most common mistake. Developers create a workflow but forget to attach it. Check Catalog Item → Process Engine → Workflow / Flow Designer If empty → tasks will never generate. Root Cause #2 — Workflow Conditions Evaluated to False Your workflow may contain condition logic: Example: Department == IT If user selects HR → workflow skips task activity. Symptom Workflow runs but stops immediately. Fix Check activity conditions inside workflow/flow. Root Caus...

  Ce qui se passe réellement lorsqu’un utilisateur soumet une demande Beaucoup de débutants pensent : L’utilisateur soumet une demande → Un ticket est créé → Terminé Mais dans ServiceNow, une demande du catalogue crée automatiquement plusieurs enregistrements, tâches et validations. Comprendre cette structure est essentiel pour les développeurs, administrateurs et équipes support. Que se passe-t-il lorsqu’un utilisateur soumet un élément du catalogue ? 4 Quand un utilisateur soumet une demande (ex : demande d’ordinateur), ServiceNow ne crée pas un seul ticket. Il crée une hiérarchie : Niveau Enregistrement Rôle 1 REQ (Request) Conteneur principal 2 RITM (Requested Item) Élément demandé 3 SCTASK (Catalog Task) Travail assigné aux équipes Une seule demande peut générer plusieurs tâches automatiquement. Relation entre les enregistrements (concept clé) Comme une commande e-commerce : Commande → Produit → Livraison Dans ServiceNow : REQ → RITM → SCTASK Cela permet à plusieurs équipes de...

How Service Requests Actually Work Behind the Portal Most beginners in ServiceNow think: User submits request → Ticket created → Done But in real implementation, a catalog request creates multiple records, workflows, and approvals automatically. Understanding this structure is critical for developers, admins, and support teams. What Happens When a User Submits a Catalog Item 4 When a user submits a catalog item (example: Laptop Request), ServiceNow does NOT create just one ticket. It creates a hierarchy: Level Record Purpose 1 REQ (Request) Parent request container 2 RITM (Requested Item) Specific item requested 3 SCTASK (Catalog Task) Work assigned to teams So one request can generate multiple tasks automatically. The Record Relationship (Very Important Concept) Think of it like an order in an e-commerce site: Order → Product → Delivery Tasks In ServiceNow: REQ → RITM → SCTASK This structure allows multiple teams to work independently while the user sees one request. Example Scenario ...

Pourquoi la plupart des équipes support mesurent la mauvaise chose Beaucoup d’organisations pensent que le SLA signifie simplement : « Résoudre le ticket en 4 heures » Mais après la mise en place, les plaintes continuent : « Le support est lent » « Personne ne répond » « Les urgences sont ignorées » Le problème n’est pas l’équipe support. Le problème est une mauvaise conception du SLA . Un SLA ne mesure pas la vitesse — il mesure la gestion des attentes . Ce qui se passe quand le SLA est mal conçu 4 Symptômes typiques : Tickets fermés rapidement mais utilisateurs insatisfaits Les agents contournent le système (fermer / rouvrir) Les urgences se perdent dans la masse Dépassements constants de SLA Parce que l’équipe mesure le temps de résolution , alors que l’utilisateur attend surtout une réponse rapide . Les 3 SLA indispensables pour un service desk Beaucoup de débutants configurent un seul SLA → erreur. Un support efficace nécessite trois minuteries : 1. Temps de première réponse (FRT...

Why Most Support Teams Measure the Wrong Thing Many organizations think SLA means: “Resolve ticket within 4 hours” But after implementation they still get complaints: “Support is slow” “Nobody responds” “Priority tickets ignored” The problem isn’t the support team. The problem is wrong SLA design . SLA is not about speed — it is about expectation management . What Happens When SLA Is Designed Poorly 4 Typical symptoms: Tickets closed quickly but users unhappy Agents gaming the system (closing & reopening) High-priority tickets buried Constant SLA breaches Because teams measure resolution time , while users care about response time . The 3 SLA Timers Every Service Desk Must Have Most beginners configure only one SLA → mistake. A healthy service desk needs three different timers : 1. First Response Time (FRT) How quickly someone acknowledges the issue. User expectation: “Someone is looking at my problem” This is the MOST important SLA. 2. Next Response Time Time between replies durin...

Comment les équipes support réduisent les tickets grâce à une base de connaissances Les équipes de support ne sont pas débordées à cause du volume… mais à cause des questions répétitives . « Comment réinitialiser mon mot de passe ? » « Le VPN ne fonctionne pas ? » « Outlook ne s’ouvre pas ? » Si les agents répondent manuellement → la file d’attente augmente Si les utilisateurs trouvent eux-mêmes → le support devient scalable C’est exactement là que l’intégration Confluence + Jira Service Management (JSM) devient essentielle. Situation sans intégration Les organisations rencontrent souvent les problèmes suivants : Augmentation constante des tickets Copier-coller de réponses par les agents Documentation existante mais introuvable Dépassement des SLA 👉 L’équipe travaille beaucoup mais la productivité reste faible. Ce que permet l’intégration Jira Service Management est connecté directement à la base de connaissances Confluence. Quand un utilisateur crée une demande → le système suggère ...