Skip to main content
Solved

Authorization Code actions via listener or approvals

  • September 18, 2025
  • 3 replies
  • 88 views
A
Forum|alt.badge.img+1

If I setup a connection using authorization code, it will always make the actions based upon the initiating user. With this setup, I need the ability to have Moveworks make actions using someone else’s access. Here are some examples where this is needed:

  1. The initiating user requests for something that requires approval. A moveworks approval process is used to manage that approval. When the approver approves it, I need that to initiate an action in the same system but now using the approver’s account as the initiating user does not have access to approve their own request.
  2. With the new listener functionality, I see no way to run any action associated to a connection that has the authorization code grant setup as there is no initiating user.

Best answer by srankich

Hi ​@andrewwhitley ,

Good news — this type of plugin is now possible with our new Notify feature in compound actions. Below is a step-by-step outline of how you can implement it. NOTE: This will require you are on our Limited Preview for webhooks.

 1. Triggering the Plugin

  • Your workflow starts with a webhook.
  • The webhook should trigger your plugin that has a listener configured; that plugin has a compound action set as its system body.
  • Make sure the webhook passes the email address of the person who needs to approve along with any pertinent details for the approval as an input argument.

2. Resolving the User

  • Within the compound action, use the input email with the get_user_by_email action.
  • This will return the user’s ID, which you’ll use to personalize the next step.

3. Sending the Notification

  • Use the Notify key to trigger:
    • An action,
    • Another compound action, or
    • A conversational process.
  • Each of these runs in the context of the identified user, so the approval request relies on their Consented Auth if the User Consent Auth connector is used within the body used in the notify block.

4. Designing the Approval Message

  • The simplest implementation is to send an initial message like: “You have a pending approval for X with the following details: Y. Please select an answer below.”
  • Follow that with two interactive buttons that trigger actions:
    • Approve → triggers an approval action.
    • Deny → triggers a denial action.
  • Alternatively you could also use a compound action or a conversational process for a more complex use case

Psuedo Code for the compound action

steps:
  - action:
      action_name: mw.get_user_by_email
      output_key: approval_user
      input_args:
        user_email: data.approval_webhook.user_email
  - notify:
      output_key: notify_output
      recipient_id: data.approval_user.user.id
      message:
        RENDER():
          args:
            approval_details: data.approval_webhook.details
          template: |
            You have a pending approval for {{approval_details}}. Please select a response below
      actions:
        - key: approve
          label: '"Approve"'
          system_action:
            action_name: answer_approval_action_name
            input_args:
              answer: '"approve"'
              approval_id: data.approval_webhook.approvalID
        - key: deny
          label: '"Deny"'
          system_action:
            action_name: answer_approval_action_name
            input_args:
              answer: '"deny"'
              approval_id: data.approval_webhook.approvalID

Please let me know if I can offer any further context!

      3 replies

      S
      • srankich
      • Community Manager
      • Answer
      • September 19, 2025

      Hi ​@andrewwhitley ,

      Good news — this type of plugin is now possible with our new Notify feature in compound actions. Below is a step-by-step outline of how you can implement it. NOTE: This will require you are on our Limited Preview for webhooks.

       1. Triggering the Plugin

      • Your workflow starts with a webhook.
      • The webhook should trigger your plugin that has a listener configured; that plugin has a compound action set as its system body.
      • Make sure the webhook passes the email address of the person who needs to approve along with any pertinent details for the approval as an input argument.

      2. Resolving the User

      • Within the compound action, use the input email with the get_user_by_email action.
      • This will return the user’s ID, which you’ll use to personalize the next step.

      3. Sending the Notification

      • Use the Notify key to trigger:
        • An action,
        • Another compound action, or
        • A conversational process.
      • Each of these runs in the context of the identified user, so the approval request relies on their Consented Auth if the User Consent Auth connector is used within the body used in the notify block.

      4. Designing the Approval Message

      • The simplest implementation is to send an initial message like: “You have a pending approval for X with the following details: Y. Please select an answer below.”
      • Follow that with two interactive buttons that trigger actions:
        • Approve → triggers an approval action.
        • Deny → triggers a denial action.
      • Alternatively you could also use a compound action or a conversational process for a more complex use case

      Psuedo Code for the compound action

      steps:
        - action:
            action_name: mw.get_user_by_email
            output_key: approval_user
            input_args:
              user_email: data.approval_webhook.user_email
        - notify:
            output_key: notify_output
            recipient_id: data.approval_user.user.id
            message:
              RENDER():
                args:
                  approval_details: data.approval_webhook.details
                template: |
                  You have a pending approval for {{approval_details}}. Please select a response below
            actions:
              - key: approve
                label: '"Approve"'
                system_action:
                  action_name: answer_approval_action_name
                  input_args:
                    answer: '"approve"'
                    approval_id: data.approval_webhook.approvalID
              - key: deny
                label: '"Deny"'
                system_action:
                  action_name: answer_approval_action_name
                  input_args:
                    answer: '"deny"'
                    approval_id: data.approval_webhook.approvalID

      Please let me know if I can offer any further context!

        A
        Forum|alt.badge.img+1
        • andrewwhitley
        • Author
        • Known Participant
        • September 19, 2025

        Amazing, this is very helpful! As a follow up, if I need to run multiple actions upon approve or deny for the user, is that possible with this setup as well?

          S
          • srankich
          • Community Manager
          • September 19, 2025

          ​@Andrew If there are more steps and logic and no additional user input required I recommend triggering a compound action instead of an http action. If you need to collect additional data from the user I recommend a conversational process.

           

          Below is the schema for system_action vs conversation_action
           

                system_action: # Calls another action or compound action.
                  action_name: # The name of the action to invoke.
                  input_args: # (Optional) Arguments for the action.

                conversation_action: # Initiates a conversational process.
                  conversation_process_name: # The name of the conversational process.
                  input_args: # (Optional) Arguments for the process





           

          IMPORTANT NOTES:

          Requirements for Calling a Conversation Action

          To ensure your action is triggered correctly, please note the following:

          Use the Conversational Process Name: When calling the action, specify the name of the conversational process itself, not the name of the plugin.

          Publish the Process as a Plugin: The conversational process will not be triggered by the notify key unless it has also been published as a plugin.

          Conversational Action input_args: These must be declared as slots in the conversational process in order to reference the data passed in as input args.

            Terms & ConditionsCookie settingsAccessibility statement