Connecteur

ServiceNow

Intégration sortante de ticketing : Vigicap y dépose des tickets.

Vos actions partent dans ServiceNow sous forme d'enregistrements, dans la table que vous choisissez (incident par défaut) et sous la société du client. Le statut est ensuite relu : résolu ou clos dans ServiceNow, Vigicap propose la clôture de l'action et ne la clôture jamais seul. Aucun niveau ReCyF n'est proposé. Pousser un ticket ne mesure pas la posture d'un client.

Ce qu'il faut créer dans l'outil

L'accès se crée dans ServiceNow, pas dans Vigicap. Vigicap ne demande jamais le mot de passe d'un administrateur : il attend un identifiant d'API que vous créez, que vous voyez, et que vous pouvez révoquer sans nous.

Où le générer

L'URL de l'instance est https://votre-instance.service-now.com. Utilisez un compte dédié avec le rôle itil, restreint par ACL à la table visée. Le sys_id de la société provient de core_company.

Rôle minimal

Compte applicatif ServiceNow en authentification de base. ÉCRITURE : le rôle doit permettre la création dans la table visée (par défaut `incident`) — `itil` suffit et `admin` n'est pas nécessaire. LECTURE : le même compte relit l'enregistrement par son sys_id. ServiceNow permet de restreindre le compte par ACL et par table, ce qui est le bon endroit pour le faire : le mot de passe côté Vigicap ne porte aucune portée.

Formulation reprise du modèle de rôles de l'éditeur, et vérifiée avant publication.

Ce qu'il faut saisir dans Vigicap

Les champs exacts du formulaire de connexion, dans l'ordre où ils apparaissent. Les valeurs marquées « secret » ne ressortent jamais vers le navigateur : elles sont chiffrées au repos et supprimées à la déconnexion.

Le formulaire commence par l'adresse de l'instance, saisie à part des champs ci-dessous. Le catalogue public ne publie pas encore si ce connecteur en demande une, ni à quoi elle ressemble — cette liste est donc exacte pour tout le reste, et muette sur ce premier champ.

Nom d'utilisateur
Mot de passesecret

Le routage par client

Ces champs-ci se renseignent client par client : ils disent sous quel compte de l'outil de ticketing le ticket doit atterrir. Une valeur erronée ne fait pas échouer l'envoi — elle le fait réussir chez quelqu'un d'autre, ce pour quoi Vigicap les vérifie au moment où vous les saisissez.

Société (sys_id)
Enregistrement core_company auquel rattacher les tickets de ce client.
32 caractères hexadécimaux
Tablefacultatif
Par défaut incident. Toute table héritant de task convient (ex. sn_customerservice_case).
incident

Ce qu'il fait, et ce qu'il ne fait pas

Objectifs ReCyF pré-remplis

Ce connecteur n'alimente aucun objectif ReCyF, et ce n'est pas une lacune : il ne mesure pas la posture d'un client.

Ce qui part vers l'outil

Ce connecteur ÉCRIT : il crée un ticket à partir d'une action du plan.

Ce qui en revient

L'état d'un ticket déjà créé revient : son statut, sa date de clôture, sa dernière activité. Un ticket clos devient une PROPOSITION qu'un consultant valide — jamais une action clôturée d'office. Une agence qui clôt son propre ticket ne doit pas pouvoir se noter elle-même dans le document que lit un auditeur.

Ce qui est lu, ce qui est conservé, combien de temps et avec quels droits : le même registre, connecteur par connecteur, dans l'inventaire des données.

Vérification

Ce connecteur a été écrit d'après l'API documentée de l'éditeur et n'a pas encore été exécuté contre une instance réelle. Il est signalé « Bêta » partout où il apparaît.

Les marques et logos cités appartiennent à leurs titulaires respectifs et identifient les outils avec lesquels Vigicap est compatible — voir les mentions légales.