Options for tasks

Tasks can behave differently depending on what settings they get. You can use them to decide who will be able to download files, where to direct them if they follow the email invite link and where they should be redirected when their signature is done.

Enable download for all signers

All tasks have associated users. One is called the creator and the others are called signers. By default, only the creator is allowed to download the task files. However, you can configure SWF to make it possible for all signers to download the files as well, as well as changing the default setting. To do this, you can update the following settings:

{
  "taskOptions": {
    "enableNotifyAllSignersOption": true,
    "defaultSignerNotification": true
  }
}
Click to copy
  • taskOptions - The wrapper object for this setting (same as enabling direct email invites)
  • enableNotifyAllSignersOption - Option to enable the functionality in the UI.
  • defaultSignerNotification - What the default setting should be. true means all signers can download the task files by default.

This functionality is available through the automation API and defaults to false, meaning only the creator can download the tasks, regardless of taskOptions settings.

Direct email invites

When a signer is in PENDING status an email will be sent to that signer. By default, if a user clicks the link in the email, they are directed to SWF where they can see all their tasks, see who is added as signer, download the files (if they have access), etc. However, it is possible for creators to direct the user directly to the preview section, or "The signature flow", to simplify the signature process. This would mean that the signer would follow this flow:

  1. Receives an email
  2. Clicks the link
  3. Logs in
  4. Gets a preview of the file
  5. When they decide to sign they sign/authenticate
  6. Lastly, they end up at a landing page saying "You're all done!"

This can make it easier for users to understand what they need to do.

This option can be used out of the box in the automation API and can be used by adding this into your task request body:

"taskOptions": {
  "inviteUrlTarget": "SWF | SIGN_SERVICE"
},
Click to copy
  • taskOptions - the task options object
  • inviteUrlTarget - The target of the email invite. Possible values:
    • SWF - The invites are directing users to SWF.
    • SIGN_SERVICE - The invites are directed to the preview/signature flow, SWF is not involved in this scenario

To set this option in the UI, the option needs to be enabled in config.json:

{
  "taskOption": {
    "enableInviteUrlTargetOption": true,
    "defaultInviteUrlTarget": "SWF | SIGN_SERVICE"
  }
}
Click to copy
  • taskOptions - The wrapper object for this setting (same as for enabling file download for all signers)
  • enableInviteUrlTargetOption - Option to enable the functionality in the UI.
  • defaultSignerNotification - What the default setting should be.

Configuring the landing page

If the inviteUrlTarget is set to SIGN_SERVICE, SWF can redirect the user after a successful signature. The user can either end up at a landing page where a text is shown along with a button that will log out the user, or redirect to another URL. Administrators can not only configure the text, but prepare landing page configs so that different task creators can utilize different landing pages for different tasks. This functionality is only available from the automation API.

To enable this functionality, completionNextTarget.enabled needs to be set to true.

Redirecting to another URL

Task creators can make SWF redirect to another URL after a successful signing. What domain to redirect to can only be set per task, and only when the task is created via the API.

Since this functionality might introduce potential security issues where task creators can set a malicious redirect URL, administrators can restrict what domains can be used to redirect to by using the same domain whitelisting as for nextTargetUrl in PAS; see PAS documentation.

The configuration of this "completion next target" can be done as follows:

"completionNextTarget": {
  "enabled": true,
  "allowedLogoutTargetPrefix": ... ,
  "allowedLogoutTarget": ... ,
  "allowedLogoutTargetSuffix": ...
}
Click to copy
  • completionNextTarget - The wrapper for the completion nextTarget configuration
  • enabled - Whether the functionality should be enabled or not
  • allowedLogoutTargetPrefix - Regex for nextTarget prefix. See PAS documentation for more information.
  • allowedLogoutTarget - Regex for nextTarget. See PAS documentation for more information.
  • allowedLogoutTargetSuffix - Regex for nextTarget suffix. See PAS documentation for more information.

When a task is created, something like the following should then be added to the task object:

"completionNextTarget": "https://google.com"
Click to copy

If the specified URL adheres to the completionNextTarget regex, SWF will redirect the user to the specified URL.

Landing page configurations

Task creators can also send signers to a landing page within SWF, where the default is a text saying "Done!" along with a button to log out the user. To update the default landing page, update the corresponding strings.json properties like this:

"landingPage": {
  "htmlTitle": "Signing Done",
  "success": {
    "title": "You are done!",
    "message": "You have signed the file.",
    "button": "Continue"
  },
  "alreadySigned": {
    "title": "The task is already signed",
    "message": "The task has already been signed",
    "button": "Continue"
  }
},
Click to copy

Administrators can also set specific landing page configurations that task creators can use via the API. To use this, the first step is to add landing page configurations to the completionNextTarget configuration:

"completionNextTarget": {
  "enabled": true,
  "configurations": {
    "landing_page_id_1": {
      "success": {
        "title": "landing_page_1.title",
      },
      "disableLogoutButton": true
    },
    "landing_page_id_2": {
      "success": {
        "message": "landing_page_2.message",
      },
      "disableLogoutButton": false
    }
  }
}
Click to copy
  • completionNextTarget - The wrapper for the completion nextTarget configuration
  • enabled - Enabling the functionality. Defaults to `false`.
  • configurations - the configurations wrapper of the landing page configuration part. This is a JSON object, meaning all landing page keys need to be unique.
  • success - A success message wrapper
  • message - The message localization key. For more information, see below
  • disableLogoutButton - Whether the logout button should be disabled. Defaults to false.

The above configuration enables two landing page configurations - landing_page_id_1 and landing_page_id_2. These are the IDs that are needed when creating a task.

Second, we must set up the localization keys associated with the IDs to decide what texts should be shown. The localization
keys, found in the strings.json file, need to be structured as follows to support the example above:

"landingPage": {
  "htmlTitle": "Signing Done",
  "landing_page_1": {
    "title": "This is my special title"
  },
  "landing_page_2": {
    "message": "This is my special message"
  },
  "success": {
    "title": "Default title!",
    "message": "The digital signing process is now finished.",
    "button": "Log out"
  },
  "alreadySigned": {
    "title": "Task already signed",
    "message": "The task has been signed previously.",
    "button": "Log out"
  }
},
Click to copy

In the configuration with ID landing_page_id_1, we set the success title to landing_page_1.title, meaning we need a corresponding localization object in the strings.json file. All localizations are preceded with landingPage, so the actual localization key will be landingPage.landing_page_1.title

Lastly, task creators can utilize the landing page configuration by setting the property called completionNextTarget to landingPageId=<the-desired-landing-page-id> to greet users with the configured landing page.

Example

Let's say an administrator sets up this configuration:

"completionNextTarget": {
  "enabled": true,
  "allowedLogoutTarget": ".*",
  "configurations": {
    "landing_page_id_1": {
      "success": {
        "message": "lp1.message"
      },
    "disableLogoutButton": true
    },
    "landing_page_id_2": {
      "success": {
        "message": "lp2.message",
      },
    "disableLogoutButton": false
    }
  }
}
Click to copy

and strings.json is configured like this:

"landingPage": {
  "htmlTitle": "Signing Done",
  "lp1": {
    "message": "ID 1 is configured"
  },
  "lp2": {
    "message": "ID 2 is configured this time around"
  }
},
Click to copy

Service A creates a task with these two attributes set:

"inviteUrlTarget": "SWF"
"completionNextTarget": "https://google.com"
Click to copy

Result: Signers will be redirected to SWF after a successful signing. The completionNextTarget attribute will be ignored since the inviteUrlTarget is set to SWF.

Service B creates another task with these attributes:

"inviteUrlTarget": "SIGN_SERVICE"
"completionNextTarget": "https://google.com"
Click to copy

Result: Signers will be redirected to https://google.com after a successful signing (the allowedLogoutTarget is set to ".*" which means all domains will be accepted in a redirect.)

Now, the administrator changes the configuration to:

"completionNextTarget": {
  "enabled": true,
  "allowedLogoutTargetPrefix", "^https?:\/\/[-a-zA-Z0-9\.-_]{1,256}\.site1\.se.*",
  "configurations": {
    "landing_page_id_1": {
      "success": {
        "message": "lp1.message"
      },
      "disableLogoutButton": true
    },
    "landing_page_id_2": {
      "success": {
        "message": "lp2.message",
      },
      "disableLogoutButton": false
    }
  }
}
Click to copy

Service C creates a task with these attributes:

"inviteUrlTarget": "SIGN_SERVICE"
"completionNextTarget": "https://google.com"
Click to copy

Result: Since the new configuration only accepts the domain site1.se, the URL https://google.com is refused. The signer will see the default landing page after a successful signing.

Service D creates a task with these attributes:

"inviteUrlTarget": "SIGN_SERVICE"
"completionNextTarget": "landingPageId=landing_page_id_1"
Click to copy

Result: Signers will see the configured text for landing_page_id_1, which is "ID 1 is configured" after a successful sign attempt.

Service E creates a task with these attributes:

"inviteUrlTarget": "SIGN_SERVICE"
"completionNextTarget": "landingPageId=landing_page_id_2"
Click to copy

Result: The users will see the configured text for `landing_page_id_1`, which is "ID 2 is configured this time around" after a successful sign attempt.

Service F creates a task with these attributes:

"inviteUrlTarget": "SIGN_SERVICE"
"completionNextTarget": "landingPageId=landing_page_id_3"
Click to copy

Result: Since no configuration is found for landing_page_id_3, the user will see the default landing page after a successful signing.

Configuring max due days

Administrators can adjust the max number of due days, meaning the number of days from the current day to the maximum due date. This can be adjusted in the config.json file by setting

"maxDueDate": 7
Click to copy

This will set the maximum due date to 7 days from the creation date.