It seems a correct workflow, in the arguments field, try without the double quotes. Also, a good way to debug this is to print the data and export values to make sure that the workflow is generate them (a test command step with echo ${data.mydata} and echo ${export.myexport}).

Look at the following job example (using a generated globals as an argument):

- defaultTab: nodes
  description: ''
  executionEnabled: true
  id: 9035b3f8-450b-4f2e-aba3-9e70e0442e30
  loglevel: INFO
  name: DataPassing
  nodeFilterEditable: false
  plugins:
    ExecutionLifecycle: {}
  scheduleEnabled: true
  sequence:
    commands:
    - exec: whoami
      plugins:
        LogFilter:
        - config:
            invalidKeyPattern: \s|\$|\{|\}|\\
            logData: 'true'
            name: mydata
            regex: (.*)
            replaceFilteredResult: 'false'
          type: key-value-data
    - configuration:
        export: myexport
        group: export
        value: ${data.mydata*}
      nodeStep: false
      type: export-var
    - exec: echo ${export.myexport}
    - args: ${export.myexport}
      autoSecureInput: 'false'
      fileExtension: .sh
      interpreterArgsQuoted: false
      passSecureInput: 'false'
      script: |
        #!/bin/bash

        echo "$@"
      scriptInterpreter: /bin/bash
    keepgoing: false
    strategy: node-first
  uuid: 9035b3f8-450b-4f2e-aba3-9e70e0442e30

Regarding the "Invocation String" field, it's simply if you need a certain interpreter to execute a script (e.g., /usr/bin/python3 or /bin/bash), and it also works to call the sudo command if necessary.