Créer un formulaire et une logique métier

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 2 minutes de lecture

    • L’étape suivante de la conception d’une application consiste à créer une logique. La logique comprend la logique de formulaire (ce que les utilisateurs peuvent et ne peuvent pas voir/utiliser sur un formulaire) et la logique métier (règles qui régissent ce qu’il advient des données lorsqu’elles sont saisies).

    IA agentique

    Créez des applications avec l’aide de l’IA agentique. Pour plus d'informations, consultez Utiliser les options de l’IA dans des applications personnalisées.

    Scripting et modifications

    Avant d’écrire du code, soyez conscient de l’impact sur les mises à niveau et l’adoption de nouvelles fonctionnalités ServiceNow. Une prudence particulière doit être prise lors de la modification des artefacts et des processus de base.

    Tenez compte des points suivants avant d’écrire un script :

    • Évaluez le besoin. La logique est-elle critique pour le fonctionnement de l’application ?
    • Déterminez si ServiceNow peut être configuré pour répondre au besoin sans code.
    • Exploitez des options telles que Concepteur de flux, Agent virtuel et les politiques d’interface utilisateur pour tirer parti des options de la plateforme sans écrire de code.
    • Les approches logiques low-code et no-code sont plus faciles à déboguer et à mettre à niveau.

    Exemples de cas où le scripting est approprié :

    • Création d’actions du Concepteur de flux
    • Création d’une API REST basée sur un script
    • Création d’une logique pour les applications incluses dans le champ d’application dans les includes de script
    • Personnalisation et création de widgets pour Portail de services

    Évaluez les besoins de l’entreprise et envisagez un itinéraire sans code avant d’utiliser une solution scriptée.

    Tenez compte des améliorations apportées à ServiceNow. Par exemple, dans la version Orlando, les conversations d’Agent virtuel offrent plus d’options sans code qu’à Londres. Lire les notes de publication et autres publications. Obtenez une certification et restez à jour avec vos certifications.

    Pour mieux comprendre quand personnaliser, consultez le playbook Innovate at Scale Success sur le Customer Success Center.

    Modification du comportement par défaut

    Dans le passé, l’une des stratégies utilisées consistait à copier l’artefact pour mettre à jour et désactiver l’original. L’approche copier/désactiver n’est plus recommandée en raison des problèmes suivants :

    • Les développeurs ne peuvent pas dire si un artefact désactivé a été mis à niveau sans recherche.
    • Deux fichiers, l’original et la copie, doivent être conservés. La maintenance double chaque fois qu’une personnalisation est effectuée.
    • À chaque version, l’enregistrement personnalisé vieillit.
      • Les clients ne bénéficient pas des améliorations incluses dans une nouvelle version.
      • Une nouvelle mise en production peut dépendre de la mise à jour de l’enregistrement d’origine.
      • Les développeurs peuvent apporter d’autres modifications pour compenser l’inactivité de l’enregistrement d’origine.

    Un script dans lequel seul le marqueur Actif est modifié est mis à jour, mais le script n’apparaît pas sur la liste ignorée. Avec la stratégie Copier et désactiver, un développeur a moins de visibilité sur les personnalisations et ne peut pas facilement évaluer ou revenir à la version de base de référence.

    Plutôt que de copier et désactiver l’artefact d’origine, modifiez-le directement. Le moteur de mise à niveau ServiceNow ajoute la dernière version à l’historique des versions et signale que l’artefact a été ignoré. Les développeurs peuvent voir qu’une nouvelle version est disponible avec la mise à niveau.