Manage viewer parties

Typically, participants in an e-signing workflow are the ones that sign or approve a document. There's also the possibility to define viewer parties. These are parties that have the possibility to view a document in a workflow.

In this article, we'll show you how to set that up.

Add viewing permissions

To keep things simple, we're going to use the basic process that we saw before in the Getting Started article related to Drafts. However, we will modify it slightly. We will add viewing permission to a viewer party in the previously-empty list of actions:

{
  "dsl-version": "0.2.0",
  "stages": [
    {
      "initial": {
        "actions": [
          {
            "allow-viewing": {
              "users": ["viewer1"],
              "documents": ["doc1"]
            }
          }
        ],
        "expect": {
          "signed-by": {
            "users": ["signer1"],
            "documents": ["doc1"]
          }
        }
      }
    }
  ]
}

Observe that the actions list now contains one item called allow-viewing. Within this object, we specify which users have viewing permissions on which documents.

In the example above, we state that viewer has viewing permissions on document doc1.

Starting the instance

Just like we did in Getting Started article related to Instances, we are going to send a JSON object detailing concrete values for the variable names in the process:

{
  "title": "foobar",
  "process_parameters": {
    "documents": {
      "doc1": "2"
    },
    "users": {
      "signer1": {
          "id_type": "user_id",
          "id": "1"
      },
      "viewer1": {
          "id_type": "user_id",
          "id": "2"
      }
    },
    "messages": {}
  }
}

Now that we have added the viewer1 participant, we are able to instantiate the draft.

Upon starting the instance, you can see the following within the instance response:

"access_links": {
    "signer1": "https://scrive.com/experimental/microapi/overview/b54dc8fb5f198d53",
    "viewer1": "https://scrive.com/experimental/microapi/overview/db19989cc087ca8c"
}

The viewer1 link allows the viewer party to authenticate, go to the overview page, and have view access to the document doc1.

Remove viewing permissions

Let's now slightly modify the process to remove the viewing permission for viewer1 after signer1 has signed the document. This means that the viewer party permission to access the document can be dynamic as the process evolves. We add a new stage to obtain this behaviour:

{
  "dsl-version": "0.2.0",
  "stages": [
    {
      "initial": {
        "actions": [
          {
            "allow-viewing": {
              "users": ["viewer1"],
              "documents": ["doc1"]
            }
          }
        ],
        "expect": {
          "signed-by": {
            "users": ["signer1"],
            "documents": ["doc1"]
          }
        }
      }
    },
    {
      "final": {
        "actions": [
          {
            "deny-viewing": {
              "users": ["viewer1"],
              "documents": ["doc1"]
            }
          }
        ],
        "expect": {}
      }
    }
  ]
}

When the initial stage is complete, the deny-viewing action specified in the final stage will assure us that the viewer1 party no longer has the possibility to view the document doc1.