Je pense que mettre la valeur en dure devrait marcher, mais c’est à tester.
La bonne pratique c’est de faire une copie de l’actuel modele d’envoi et de faire des tests sur la copie.
Les variables sont assez simple à comprendre, surtout une fois la clé de lecture comprise.
la première partie « SaleOrder », c’est la table de référence de l’application.
SaleOrder represente une des tables de l’application « Ventes » du bon de commande (pour le client).
Ensuite « company » c’est la variable de la table « saleOrder » qui indique la société qui émet le bon de commande. Donc votre société en tant que vendeur.
Mais cette variable « company » est en fait un lien vers une autre table, et « partner » une variable de « company » qui va orienter vers la table des « partner ».
« partner » signifie au niveau d’Axelor, bcp trop de chose (clients & fournisseurs). Vous avez défini un tier/patner en tant que société client+fournisseur : Votre société.
Donc de la table « company » qui lie votre fiche « partner » (votre société) en gestion de l’application vente : vous prennez la variable « emailaddress » de ce partner, et la variable « address » de la table des « emailaddress »
Vous êtes perdu ? Alors comprennez ceci :
Pour gérer les données, les developpers ont créés des tables pour … TOUT.
Si on veut créer une adresse postale, une adresse email, un client ou un produit.
On crée la donnée,
Et ensuite on l’attribue aux tables concernées.
Mais pour l’attribuer, il faut un lien, et donc une variable d’une autre table, qui indiquera, l’ID, le nom et la version.
Oulà mais ca fait des doublons de partout ? - Je ne sais pas. Je ne suis pas développeur et je ne travaille pas chez eux 
La gestion des tables est complexe et je vais me permettre un lien vers mon fil sur ce forum au sujet de n8n. Si vous avez déjà des connaissances API et BDD, ce sera accessible pour vous. si non voyez si ca vous interesse.
Have fun