Form is the basic element of workflow process. Thanks to it, users have insight to information included in attributes or attachments, they work on them entering new information/ modifying previous ones. In order for users communicate with system, they need to get suitable interface.
Article shows the concept of “Field matrix” – a mechanism responsible for presentation of data from system. In second part, information about detailed Form field configuration were attached and configuration of oversaving of matrix configuration was discussed.
Content of WorkFlow form may differ depending on many elements, differences may occur at:
1) Step in which the document is
2) Role of the person browsing the document (author, person with the task, read-only, superior or HR department)
3) Values (for example visibility of attributes in dependence from the values in other fields)
- “Depending on”
The process with already created attributes is recognized as the basis of this article. In BPS designer we will find Fields matrix by going step by step through process tree:
Second part which we are interested in, is Permissions tab – available for most of the Form fields:
Field matrix – basics
Field matrix is the most basic and obligatory element which defines visibility of certain attributes on document form. There is no possibility of showing the form field on the form if it is not visible on the matrix.
Matrix consists of three blocks, where we will find form fields placed accordingly to the place in form template. Respectively:
1) Left panel – responsible for form fields placed on the left part of the form (without information bar)
2) Right panel – responsible for form fields placed on the right part of the form
3) Position list – elements on the bottom of the screen
In this article, placement of the form fields is irrelevant.
Every form field is definable separately, depending on the step in which the document is in. It means that, if for example on the registration step we can show 3 of 5 elements and then on the second step additional two. Important information concerning edit ability of the form are two cases:
1) Form edition (button on EDIT/Cancel edit)
a) If we are not in edit mode, the form, by default shows all visible attributes in read-only mode
b) If we are in edit mode, then the form will generate itself according to configuration of availability of edit visibility and requirement of form fields.
2) In order to gain access to edition of the form you need to have one of the following permissions:
b) Modification permission (automatically given in the moment of task generation)
Screen below shows available form field configuration possibilities on the matrix level
There is few possible states of the form field:
1) “Date” form field will not be seen on the step, same time it will neither be required nor editable
2) “Person” – form field visible, editable, not required
3) “Text” – visible, grayed out (similar to edit but edition is locked), not required
4) “Number” – visible, read-only
5) “Yes/No” – visible, editable and required
6) “Dropdown” – visible, read-only and required
Combinations above may be used regardless of form field (in exception of “Data presentation” fields – required setting here, will not have any effect). Form field setting as above, will present in the following way:
1) Date – field is invisible on the form
State used when we register for example invoice document. Person fulfilling the document may not have knowledge about analytical breakdowns for invoice. In such situation there is no need for that person to fulfill such data.
2) Person field is editable for the user
Mode used when we want to give the user a possibility of changing the value of the field. The field is not required (red dot) so it may be left empty and it will not be possible to register the document.
3) Text – on screenshot it is filled with default value, but it is read-only field
User will not be able to change the value in this field. Mode used for example to set default value: for the registering person it could be login of current user.
4) YES/NO in read-only mode
Similar to mode 2, but less controls were generated on the form (page looks lighter) – mode has influence on speed of loading, it should be used if there are many attributes or in situations where we do not want to give the possibility of edition.
5) Dropdown – edit mode, required
State used when we want the user to fill the field. For example in vacation process, when we send application for acceptation – as required and editable we will set fields of start and end date of user vacation.
6) Number – read-only, required
State used very rarely, in situation where we want additionally check (force requirement) of attribute fulfillment for example before ERP registration, when field with number of bank account fills itself automatically (on the basis of another field with SQL data). If such field is empty, the document will not go through the given path (with standard requirements settings)
It should be stressed out that in most cases configuration of form visibility through fields matrix is completely enough and there is no need to create additional restrictions for specific form fields.
Permissions – Form field tab
Form fields, in their configuration, have few possibilities of visibility, edition or required settings. It is possible to configure these values through field matrix, but there is possibility of oversaving those through configuration of specific sections in form field itself.
Permissions section consists of:
1) Visibility restriction – influences visibility of given attribute. It is important that the element is visible on attribute matrix. Otherwise setting on permissions tab will not influence it.
2) Edition restriction – influences availability of attribute for user edition. Similary as with visibility (point 1) field matrix configuration is important. For example it is not possible to make form field editable (from permissions tab) if it is not editable on field matrix.
Permissions – visibility restriction
Visibility restrictions divide themselves in subdivisions. Visibility may be set depending on couple elements:
1) Visibility restrictions for persons (AD accounts, AD groups, Sharepoint groups)
- Setting used in HR processes, where sensitive data exists and we want only dedicated group of people to see them.
- To define form field visibility person/group, it is enough to write down names of persons or groups in the field below:
- In effect the form field will be shown on the form if that person will use it from his user account
In case if we will write down another user, for example Director/CEO/HR group, in which there is no current user – field will not be visible on the form.
2) Visibility restriction for everyone using SQL query.
Action very similar to the one above. The difference is to create such SQL query, which will return 0/1 value. If it returns 1 – form field will be visible on the form. If it will return anything else but 1, form field will not be visible.
Using that option we may choose the source which we want to examine (“Data source for query” option is used for that), after defining data source in Designer we will be able to choose it here.
While creating a query, we may use values available in another fields. On the example above, “Number” form field was confronted with 32 value, if the value is equal 32, form field will be visible, otherwise it will not.
3) Visibility restriction for specific persons on the basis of SQL or CAML
Option used in situation when we want to return logins of persons for whom the form field cannot be visible. For example we may examine view with data from ERP system.
Similarly to point 2, we may define data source.
Very important case is summation of conditions. If any of the written above will restrict access to attribute then it will not be shown on the form.
Permissions – edit restrictions
Similarly as with visibility restrictions, there is possibility of configuration of form field edit availability.
1) Form field administration
Element available to configuration with two predefined options
- No one
- Author – person registering the document
- Persons with access to the element
Important case is the fact that administration of form field is independent from settings on attribute matrix – it is enough if the form field will be visible. Administration of the attribute takes into account configuration of editability of specific field in further parts.
In persons field, persons/AD or SPS groups may be chosen. For the configuration to take effect, given element on fields matrix has to be left for edition:
If the person using the document will find itself in configuration, then the form field will stay for edition, otherwise edition will be locked.
3) SQL query restricting edit ability for everyone
Similarly to visibility – to set form field as editable it has to return 1.
4) Requirement restriction
For using that option, the form field has to be set as required in the fields matrix
Option available for oversaving of form field requirement. Restriction is created using SQL query. If we want it to be required, then as the result of query we should return 1.
Restriction is used in case if filling of the specific field is dependent on value in other form fields. For example if we have chosen client we may set bank account number field as required.
Report and history restrictions
With visibility and edit ability configuration, another checkboxes, corresponding to form field visibility on SWE reports or in history, are available.
By default checkboxes are unchecked – it means that filling a given condition or person in restrictions section will cause that on SWE report or element history, attribute will not be visible. If checkbox will be ticked then the given restriction will be ignored.