Invited User Example
This application demonstrates how to use the “Invited User” pre-defined group in the Access permissions. You may use the “Invited User” feature when you need to collect information from a user that is not known (or part of) in your corporate LDAP. The invited user is sent an “invite link” that will enable them to access the Leap record without having to authenticate. The user will then be able to fill out the form and submit just as if they were an authenticated user.
Note: The “Invited User” feature can only be used for subsequent stages because Leap can only generate invite links from an email as part of a submit activity.
This article will go into a little more detail and provide screenshots of the required steps.
Design
In this article we will not go into the content of the survey/sample. The only requirement to using the “invited user” feature is that the user filling out the form needs to supply an email address for that user to be invited. The email provided will then be used in the email setup which will be covered in the upcoming Stages section.
Stages
The typical survey only consists of the Start and End stage. The Start stage is the act of filling out the form. The submit button will be added automatically and will move the survey from the start stage to the end stage. Once a form is in the end stage it can no longer be updated. In this example, after the first user submits the form we want to advance it to a stage where it can be edited by our invited user. So we add an additional stage called “Review” by clicking on the green plus at the top of the panel. Once the stage is added, we can expand it and modify its properties.
Note: In this example I have hidden certain sections of the form based on the stage that they “belong” to. For example, I don't want the initial user to see the section that will be filled out by the friend, so I hide it by clicking on the “click to hide in this stage” icon in its upper right-corner!
There is an email that is configured as an activity of the Submit button for the Start stage. The email references the email field on the form as the “to” field and includes an invite link that the recipient will click to access this submitted record.
Access
Who has access to fill out your survey is controlled by the settings on the Access Tab. To make a survey available to invited users we need to add a role and then setup its permission.
Select Define Roles and then click the green plus to add a new role. I called this role “Invited”:
Now that the role is created, lets define its members. Click on the role that was just created, and add the “Invited Users” group.
Now that the members of the role are defined, lets check the permissions in each stage. First click on Start under the Stage Settings...Form 1. We do not want the invited user to have any permission in the start stage (it doesn't make sense) so we will leave it at the default setting:
Then click on the name of the next stage (Review), in this stage we want the invited user to have read and update permission.
At this point the Access and Stages are configured and we can test our application. When the first user fills out the form you can see that they are authenticated (but we could have just as easily made it anonymous). When the invited user access the application by clicking on the link in the email they receive they will be registered as a guest:
Next select the End stage. The table here depicts who will have access to review the submitted records from the View Responses page. If you only want the application administrator to review the submitted records then you would give the Administrator role read access and remove it for all the other roles. If you have a group of people that should have access to view the submitted records then you should create a new Role – do not add them to the Administrator role. The Administrator role is for people that can edit the application and you should be selective about who gets access.
You can add additional Roles by clicking on the Define Roles button. Add a new Role for your review group and then give that group the necessary Read permission in the End stage. Note that the role is “closed” this simply means that it is static and cannot be changed programmatically. If you want to dynamically assign users to a role then you will have to set it to “open” but that will be discussed in a later topic.
At this point you should now understand the basic premise of using the “Invited User” pre-defined group and can start applying it to your applications where it makes sense.