Part 1: The Problem

Employees periodic assessment is an important and tedious repetitive process for the HR department. As a leader in Software Development, Quercus Solutions decided to computerise its employees assessment process. I was charged with implementing a simple, affordable, and extensible solution using a non code InfoPath Form and a declarative SharePoint Designer 2010 Workflow.

Process Description and Security Constraints

Quercus Employees assessment process involves four parties, the employee himself, his coach, the HR department, and the company manager. One big concern is to keep the assessment data completely private and secure.

The assessment  process consists of multiple stages.  The following flowchart shows these stages.

Assessment Process

To start an assessment, the HR manager should create a new assessment Form. He/she, then, fills a view of the  form that includes some basic parameters such as: employee name, coach name, etc. We plan, in a future release,  to automate this step using a SharePoint employees External List and a Timer Job. When a Form is created, no body Should be given access to it, except the HR Manager.

The second stage starts when the HR manager decides that the process of assessment is ready to go. At this moment an alert is sent  to the coach. It should give him a link to the assessment Form that he should fill. As a part of filling the assessment form, he should decide about a meeting date with the employee to discuss the assessment.

At this second stage,  the coach should be the only person that have write access to the Form. The HR and the company manager should only have read access. Neither the employee himself, nor any other person should be able to access the Form at all.

The third stage starts when the coach signals that he is finished with the assessment. The coach can edit and modify the assessment as many times as he wishes, however, he can’t modify it once he marks it as ready for the next stage.  An alert is, then, sent to the employee to ask him to revise the assessment and to inform him of the meeting date.  The body of the alert should include a link to the assessment Form. The employee should  be able to navigate to the Form and read his coach assessment. He can enter his comments and specify his future goals for the next period.

While doing so, the employee should not have any write access to the part of the Form containing his coach assessment. However, he should have write access to the part of the Form including his comments and his goals. Any other involved party, even the coach, should have, only, read access to the Form. You may wonder why we don’t permit the coach to modify his assessment? This is because we don’t want him to change the Form while the employee is viewing it. Any other person except those involved in the process should not be capable of accessing the Form by any means. In particular, he or she must not have the permission to download the form to his/here computer and open it with an XML editor

The fourth and final stage starts after the employee completes his review. In this stage the coach and the employee meet  together  to discuss the assessment. The coach should be able to change his assessment in case he have new evidence resulting from the meeting. He, also,  should  be able to terminate the assessment process. No other party could be able to modify the Form. Non involved parties, should not, even, be able to access the Form.

Once the coach marks the assessment as completed, no other person except the HR manager and the company manager could  be able to access the Form. This is true even for the coach and the employee.

Outlines of the Solution

The solution is based upon a non code InfoPath Form published to a SharePoint InfoPath Form Library. The Form is accessed with InfoPath  client filler; i.e., the form is not web enabled. The design justification of this choice is the  need to use InfoPath User Rules combined with InfoPath  Views to control access to the different parts of the form. As User Rules are not supported in InfoPath web Forms, we  excluded it in the first implementation. The other rational is that all Quercus employees have InfoPath filler installed on their computer. At the end of this article I will devote a section on how to use InfoPath Web Forms instead of InfoPath filler.

The solution uses also a declarative workflow developed with SharePoint Designer 2010 to alert the involved parties and control the  process flow. It also sets SharePoint items permissions on the Form Library using a workflow Impersonation Step.

In Part 2 of this article I will explain the implementation in details.