This is more of a helpful tutorial than a question, Its something I have used to help with the way our forms function within our company. This may or may not work for you, but I wanted share it since it has worked so well for us.
Definitions:
-
InfoPath UserRole: the user roles defined within InfoPath
-
UserRole: The actual user role of the end user Ex: Manager, Approver
One of the problems we have with InfoPath is the InfoPath UserRole and how it relates to the actual UserRole. This of course relates also to how InfoPath deals with the separation of Data and Functionality. We needed a form that could be tested easier, UserRoles changed easier, and new Users added easier. To do this without modifying the form became the challenge. So we took the seperate Data approach, remove the data from InfoPath and put it into a Sharepoint List that is managed by one group.
For this to work, you have to be able to pull the secondary data source from sharepoint (as a list) and get a username of some sort within InfoPath (using Webservices, code, etc.) then link the two together.
How and why does this work better than the InfoPath UserRoles?
You can add/change/delete users with ease?
Ex: You have a form with 25 users, 20 are A users, and 5 are B users. In InfoPath, you have to add them as such. If someone quits/changes positions/etc. You have to modify your form.
Using the seperate Data approach if someone quits/changes positions/etc, you only change/delete from the list and its done, no uploads, no form modification, no end user updates, etc.
When you have multiple roles on one form, this becomes invaluable for testing. You can go from being role A one minute to being role B the next, and you don't have to modify your form.
This also takes the person out of the form, and only uses the Role of the person.
Ex: Bob is the Manager, with InfoPath UserRoles, you use Bob throughout the form as Bob, his role within the form could be Manager, but he is still Bob.
Using an external list, Bob no longer matters, only the Manager matters. Why, because the User Role is what matters.
Bob is the Manager, so is Betty and Brenda, all three could are Managers, but only Manager matters within the form.
You can combine the Persons within one UserRole using InfoPath UserRoles, but then Example one comes into play again.
It it a time saver.
Ex: You have 5 forms, all forms use the same UserRoles. Using InfoPath UserRoles, you have to enter them in every form, which can take a long time. You could copy a premade form with the UserRoles assigned already, but when someone quits/changes positions, Example one gets multiplied by the number of forms you have.
Using the seperate Data approach, you only have to add 2 fields, and 1 data connection and its done.
How do we do this?
This does takes some work on the designer of the form in the beginning, but in the end, you have a form that is A: easier to test, B: easier to add/delete/change Roles of users and C: you don't have to modify the form to change roles again.
In Sharepoint, create a new custom list, Form Users is a good name.
The default columns I recommend are Name, and Role. You can add Email as well or anything else you may need.
In InfoPath, you will need 2 new fields and 1 new data connections (or 2 if you use UserProfileService.asmx to get user names, or another webservice)
Add the sharepoint list Form Users as a data connection, with Name and Role being used from the list.
Add 2 fields, UserRole and UserName (change names as needed), and UserEmail if you added it to your list.
In the Rules on form open, add the rule, SetUserName (change name as needed), this rule should set the UserName field using whichever way you use to get the current user's name, whether by UserProfileService.asmx, code, etc.
In the Rules on form open, add a rule under the previous, setUserRole(change name as needed), this rule should set the UserRole field.
-
Set the field to the Role from the Form Users data connection
-
Filter and add where Name on the Form Users data connection is equal to UserName. (This is why the name that goes into the UserName field should match the Name on the Form Users list from sharepoint)
You can then use the UserRole field as a way to hide, validate, etc other fields. So that only certain User Roles need to fill out certain fields. Ex: Managers may only be required to fill out 1 field, but an Employee may be required to fill out 10 fields.
Hopefully this helps someone out, if you have any questions, let me know.
GM