You can define security for a Web Client profile. This determines which users will be able to see the profile when it applies to a contact. This can be useful for limiting a profile to a specific group of users. For example, you could create different sets of profiles for different departments, then use the security options to ensure that users only see the profiles relevant to their own departments.
Note that security for Web Client profiles is separate than the security for the folders that may contain the information displayed. Granting a user access to a Web Client profile does not override or change that user’s access to the underlying InterAction data. If a user does not have read access rights to information from a particular folder, the user will not be able to see the information, regardless of security for the profile.
For example, the Client profile included with InterAction includes fields from the Client Financial Information folder. Many organizations set access rights for this folder to limit the users allowed to see the financial information. However, the Client profile itself is available to all users. Users with read access to Client Financial Information will see the complete profile; users without this access will see the other fields, but not the financial fields.
For more about how profiles work in conjunction with folder access rights, see Web Client Profiles and Folder Access Rights.
You can set the security for a Web Client profile to the following:
- All Web Client Users (this is the default for a new profile).
- Any combination of specific users and specific user groups.
This section covers the following topics:
- When Would I Restrict Access to a Web Client Profile?
- Grant All Web Client Users Access to a Profile
- Restrict a Profile to a Specific User or Group
When Would I Restrict Access to a Web Client Profile?
There are two main reasons for restricting access to a Web Client profile – making the application easier to use by hiding irrelevant information, and limiting an “under construction” profile to an administrator or pilot group.
Hiding Irrelevant Information
Keeping irrelevant information out of view helps end users to find the information that is relevant to them. For example, you might allow your clients to access limited information in InterAction by using the Web Client as an extranet. In this case, the information presented to clients will likely be different from that presented to internal users. To accomplish this, you could set up two sets of profiles – those for internal users and those for external users. You can then use the profile security options to ensure that each group of users only sees the correct set. This is important, since the “slimmed down” version for clients would only clutter up the view for internal users.
A similar situation could occur with different internal groups. For example, you might want to have a series of “client” profiles that are specific to the various departments in your organization. These profiles might all use information from shared information folders, such as the client number and financial information. A client that is actually a client within two different departments would display two different “client” profiles, which would clutter the display and make it more difficult for users to find the information they need. To solve this, you can set the security for each profile to a user group that corresponds to the department.
Temporarily Hiding an "Under Construction" Profile
If you are adding a new profile to the system after the initial rollout (so users have access to the Web Client) it is not a good idea to expose it to all users until your organization has done the following:
- Populated the necessary folders with initial contacts
- Filled in the fields that will be displayed where possible
- Tested and reviewed the profile in the Web Client and confirmed that it displays the correct information.
To accomplish this, you can set the security for the new profile to a few users or a pilot group (see Restrict a Profile to a Specific User or Group). Log on to the Web Client as this user to test the profile. Once it is ready to go “live,” change the security to open the profile to all users (see Grant All Web Client Users Access to a Profile).
Note that this is not normally necessary when you are working on the initial rollout, before professional end users have access to the Web Client.
What About Protecting Sensitive Information?
Keep in mind that security on a Web Client profile only applies to viewing the profile; it does not change a user’s rights to the underlying data. So if a user has read access to the folder that contains sensitive information, but does not have access to see a profile that displays it, that user could still see the information through other means, such as the Windows Client (if the user had access to that application). Therefore, when working with sensitive information, you should use folder access rights when possible to ensure that the information is protected.
Grant All Web Client Users Access to a Profile
- Log on to InterAction Windows Client as a user with permission to create contact types.
- The Manage contact types permission is required to create or edit Web Client profiles. This is because profiles are typically created in conjunction with contact types.
- This permission is granted using InterAction Administrator. For details, see Give Users Permission to Manage Web Client Profiles.
- Edit the profile you want to change, as described in Edit a Web Client Profile.
-
Under Security, select the check box All Web Client users can view this profile.
If the profile previously had security set to users or groups, you do not need to remove those accessors first. They will be automatically removed after you select All Web Client users can view this profile and save the profile.
- Choose OK to close the dialog box and save your changes.
-
Choose Close to close the Manage Web Client Profiles dialog box.
Your changes become available in InterAction Web Client after the next InterAction Application Server cache refresh. For details about manually refreshing the Application Server cache, see Refreshing the Application Server Cache.
Restrict a Profile to a Specific User or Group
- Log in to InterAction Windows Client as a user with permission to create contact types.
- The Manage contact types permission is required to create or edit Web Client profiles. This is because profiles are typically created in conjunction with contact types.
- This permission is granted using InterAction Administrator. For details, see Give Users Permission to Manage Web Client Profiles.
- Edit the profile you want to change, as described in Edit a Web Client Profile.
-
Under Security, clear the check box All Web Client users can view this profile if it currently selected.
The Add and Remove buttons will become enabled.
-
Use the Add and Remove buttons to create a list of accessors. Each user or group you add will be able to view the profile for contacts in the Web Client.
To Do This Add a specific user as an accessor Choose Add, then select Specific User. You can enter the user’s account name, or choose the browse button to look up a user by last name.
Once the user is selected, choose OK to add the user to the list.
Add a specific group as an accessor Choose Add, then select Members of the Group. Select the group from the drop-down list.
Once the user is selected, choose OK to add the group to the list.
Remove an accessor from the list Select the user or group from the list of accessors and choose Remove. Remove all accessors and grant access to all Web Client users. Select the All Web Client users can view this profile check box, then save the profile. - Repeat step 4 for each user or group you want to add to the list of accessors.
- Choose OK to close the dialog box and save your changes.
-
Choose Close to close the Manage Web Client Profiles dialog box.
Your changes become available in InterAction Web Client after the next InterAction Application Server cache refresh. For details about manually refreshing the Application Server cache, see Refreshing the Application Server Cache.