Data input via Forms, using Roles to partition user activities.

For a demo example of following steps, here is the policy timestamp: 1675164605.096601003


Construct a policy in which one group of users can individually fill in and submit documents for approval and view their own documents’ status, and another group of users can view and take approve/reject actions on any of these user documents.


  1. 1.
    Assign ‘User’ and ‘Approver’ roles to users to partition them into groups where one can fill in forms and send resulting documents to approvals, and the other group would ‘approve/reject’ these documents.
  2. 2.
    Create schema and necessary policy elements to enable ‘form-filling in and submission’ and ‘approval’ workflows.


Create 3 containers which will be responsible for choosing a role, submission and approval documents correspondingly.
Assign these containers to appropriate Permissions: ‘no_role’, ‘User’, or ‘Approver’, and add the first containers into the RoleSelectionBlock.
See detailed information about the Roles in Example 1.
Creating Roles and adding RoleSelectionBlock

Main section

Creating the document

1. Create a schema for Policy data input

1.1 Go to ‘Schemas’ tab and create a new schema
Creating new Schema
1.2 To make sure there is some demo/test data content in this schema create 3 fields:
  • Organization name of type ‘String’
  • Start Date of type ‘Date’
  • End Date of type ‘Date’
  • Amount of type ‘Number to represent the amount of CO2 emissions for the time period (between the ‘Start Date’ and ‘End Date’)
Creation of 3 fields

2. To perform data input into the Policy the ‘requestVcDocumentBlock’ will be used

2.1 Since the scope of this example includes input of multiple documents the Policy requires logic similar to what is known as ‘loop’ or ‘iteration’.
For this ‘interfaceStepBlock’ is required with ‘Cyclic’ option enabled. This will allow to return to the initial state after the document was saved.
InterfaceStepBlock is added as cyclic_container
2.2 Add ‘requestVcDocumentBlock’ into the ‘cyclic_container
Adding requestVcDocumentBlock into cyclic_container
2.3 Then select the previously created Schema
Selecting already created Schema
2.4 Select ‘New UUID’ to configure automatic generation of unique IDs for each document
Selecting UUID
2.5 By default ‘requestVcDocumentBlock’ is displayed as a Form covering the entire page. To prevent this choose ‘DIALOG’ value for the field ‘Type’.
Selecting DIALOG as Type

3. Save documents in the Database.

3.1 Add ‘sendToGuardianBlock’ into the container ‘cyclic_container’ immediately after ‘create_new_document’
Adding sendToGuardianBlock in container cyclic_container
3.2 Select data type and where to store the document
Selecting Data Source and Type
3.3 Create appropriate attributes to capture/store document status
Add ‘Status’ attribute and set the initial ‘New’ value for new documents
Adding Status Attribute with New Value

Displaying the documents

  1. 1.
    To display documents ‘interfaceDocumentsSourceBlock’ is used
1.1 Add ’interfaceDocumentsSourceBlock into the ‘user_roles container
Adding interfaceDocumentsSourceBlock into user_roles container
1.2 Specify the needed columns, their titles and where the values will be taken for display
Specifying paths, type and titles of the columns
1.3 To retrieve the data from the database ’documentsSourceAddon’ block is used
1.3.1 Add ‘documentsSourceAddon’ to theuser_grid
Adding documentsSourceAddon to retrieve data
1.3.2 Select where to retrieve the documents from
Selecting VC Document
1.3.3 Select the schema upon which the selected documents should be based on
Selecting Schema
1.3.4 Select Owned by User checkbox which would filter in only the documents that are created by this user (this will disable the ability to view other documents)
Selecting Owned by User checkbox

Approving the documents

  1. 1.
    To display documents ‘interfaceDocumentsSourceBlock’ is used
1.1 As in the previous section we added ‘interfaceDocumentsSourceBlock and configured displayed columns
1.2 Add additional column which would contain the ‘Approve’ button
Adding Approve column
1.3 Since the Approve button should be displayed only for new documents use two ‘documentSourceAddon’ block
Adding two documentSourceAddon Blocks
Configure both ‘documentSourceAddon’ blocks similarly to how it was in the previous sections, except here do not select the ‘Owned by User’ checkbox to allow the Approvers to see all documents (created by all users)
1.4 Separate the documents by status by means of creating the corresponding filters
Creating Equal status filter
Creating not equal status filter
  1. 2.
    To enable actions (in this example ‘Approve’ and ‘Reject’) the ‘buttonBlock’ block is used.
2.1 Best practice is to wrap the ‘buttonBlock’ block in a container
Switch off the ‘Default Active’ option to avoid specifying the button as an independent element and hide it
2.2 Create 2 buttons for ‘Approve’ and ‘Reject’ correspondingly.
2.3 ‘buttonBlock’ is responsible only for the actions, in order to save the refreshed status of the documents.
Create 2 ‘sendToGuardianBlock’ blocks with the corresponding values for the ‘Status’.
2.4 By default blocks are always directly connected to the next block (just below it). To decouple the blocks select ‘Events’ tab and switch off the default events for both blocks.
2.5 Connect events from the ‘buttonBlock’ with the corresponding ‘sendToGuardianBlock by selecting the Events tab and create 2 new events.
  1. 3.
    Return to the grid settings and add the created buttons into the previously prepared column
3.1 Set ‘Type’ to ‘BLOCK’
3.2 Set ‘Bind Block’ to the block which we can place into the column
3.3 In order to display the buttons for only new documents set the corresponding value for the ‘Bind Group'


1. Choose a role

2. Create new document

3. Approve