Implement Roles-Based Logic in InfoPath Forms

When we create business solutions that leverage Microsoft InfoPath Forms Services (a MOSS Enterprise edition feature), we often see the need to hide or disable sections, buttons, fields or entire views based on the logical role of the user. For instance, we’d may want to show an “admin” button that allows a user to switch to an admin view showing useful state or audit information about the InfoPath form that shouldn’t normally be visible to “ordinary” end users.

It’s easy enough to determine the ID of the current user who is viewing the form via the username() function and in some limited cases, we could try to leverage that to meet this kind of requirements. However, there are two major problems with this approach:

• 1. We’d have to hard code user names in our logic with all the attendant issues that go with that.

• 2. The username() function doesn’t work well in an forms based authentication environment (FBA).

Admittedly, it’s fairly rare to use InfoPath in an FBA environment, but if you need to identify the current user’s role, you can’t use the username() function. The technique described by this tip solves that problem.

The Solution

This solution leverages SharePoint’s item level security model. The idea goes like this:

• Create a custom list. Don’t add any custom columns - the standard Title column is sufficient.

• Add one entry to this custom list for each role. For example, add “Admin” and “Approver” roles.

• Define security access at the item level for each of these roles.

• Add a data source to your custom list pointing to the custom list.

• At run-time, your InfoPath form attempts to read the specific row in the list based on the row’s title. If the run-time user has read access to the item, they belong to that role. Otherwise, they do not.

Let’s quickly walk through this scenario. We’ll perform the following tasks:

• Create a custom list, add a few role-type entries and define appropriate item-level security.

• Create an InfoPath form with the following:

• Data source linked to the custom list.

• A few Boolean fields to mark whether the current user is a member of a role.

• A rule that fires when the form is opened that determines whether the current user has access to the role-specific row in the custom list.

In order to follow along with this tip, you will need two separate user ID’s (to test out different roles), a sandbox environment where you can create a custom list and the ability to publish an InfoPath form.

Create a custom list

Create a custom list in your favorite sandbox environment. Add two rows where:

• Row 1 title = “Admin”

• Row 2 title = “Approver”

When complete, your list should look similar to the following:

Access the Admin item and break its inheritance to allow only your favorite admin account read access. First, access the list’s permissions as shown:

From there, “break inheritance” as shown: