Building Permit Application Solution: User Roles

This is the second installment in a series about the building permit application, an end-to-end solution built entirely with the 2007 Microsoft Office release. The last post provided an overview of the solution and explained the “design once” concept of Microsoft Office InfoPath 2007. This post focuses on how user roles are implemented in the solution.

Because the InfoPath user role feature is not supported in browser forms, a RoleID node was added to the data source to identify the role of the current user. The possible values for this node are 1 (the current user is the applicant, the default value), 2 (the current user is the compliance reviewer), and 3 (the process is complete and the form is approved). The RoleID node value is updated each time the form file is submitted to the document library by a Microsoft Office SharePoint Designer 2007 workflow that is associated with that library.

The RoleID node drives much of the form logic, including which view to display to the user when the form file is opened in InfoPath. Within the Open and Save tab of the Form Options dialog box, rules have been created that switch the form view depending on the RoleID value. For example, if the RoleID value is 2, then a rule will fire that switches to the Reviewer view, as shown in the following figure:

In addition to its part in determining which view to display when the form is opened, the RoleID node is integral in rules that are executed each time a user submits the form file to the document library. For example, the PermitStatus node—with possible values of OPEN, APPROVED, and REJECTED—is set during the submit operation based on the RoleID value and responses in the COMPLIANCE REVIEW section of the form. If the compliance reviewer submits the form without a rejected requirement (that is, a requirement node value equal to 2), then the PermitStatus value is set to APPROVED. The conditional logic for that particular rule is shown in the following figure:

The RoleID node is also used in the submit rule that sends an HTML snapshot of the current view to the applicant. In my next post about this solution, I will explain how an e-mail submit data connection is used to send that snapshot.

2 thoughts on “Building Permit Application Solution: User Roles

  1. Hi
    Thx for the post..was wondering how I can do this.

    But, please tell me how the RoleId is set in the first place. I assume RoleId is a from field. So, the value of roleid needs to be derived from the current user details.How is this done..Please help


  2. Hi, Clara.

    Yes, the RoleID is a hidden field in the form template. In my solution, the default value for this field is "1", which represents the applicant. So, when a form is first filled out, the RoleID value will be "1".

    After the form is submitted, the RoleID value is modified as a result of logic in the SharePoint Designer workflow attached to the form library. See my post about the SharePoint Designer workflow for this solution ( for more details.

    I hope this helps…


Comments are closed.