Creating a new user

To add users, click the Setup link and follow these steps:

1. Click the Users link under the Administer ⇒ Manage Users heading on the sidebar.

   A users list page appears.

2. (Optional) Use the View drop-down list if you want to select from standard or custom list views of your users.

   Salesforce presets your views with three standard options: All Users, Active Users, and Admin Users.

3. Click the New User button to add users one at a time.

   A New User page appears in Edit mode.

   To enter a list of users that need to be created (instead of one at a time), click the Add Multiple Users button instead.

4. Complete the fields, paying close attention to selecting appropriate Role and Profile values.

   Select the Generate New Password and Notify User Immediately check box at the bottom of the New User page if you want the user to immediately receive an email with her username and temporary password. If you’re in the midst of an implementation, we recommend deselecting this check box and doling out passwords when you’re good and ready.

   If your company is just starting out with Salesforce, be cautious and don’t give all your new users the System Administrator profile. Future generations of users at your company will thank you for taking a prudent approach to configuring things in Salesforce, as opposed to allowing too many cooks into the Salesforce kitchen.

5. Click Save.

   The User detail page appears.

Activating and deactivating users

After you’ve created a new user, you can activate or deactivate him. Activation means the user is able to log in to Salesforce and start using it. Deactivation means, well, the opposite. There is no concept of deleting a user, which helps with compliance and auditing purposes, as well as avoiding a lot of complications when it comes to historical records owned by and actions performed by that user.

To activate or deactivate a user, click the Setup link and follow these steps:

1. Click the Users link under the Administer ⇒ Manage Users heading on the sidebar.

   A users list page appears.

2. Click the Edit link to the left of a user’s name.

   The User Edit detail page appears for that user.

3. Check the Active box, depending on what you want to do.

   If you see a checkmark, that means the user is active. Removing the checkmark means that user is deactivated.

4. Click Save to save your action.

   You’re returned to the user list page.

Freezing users

What if the user you’re trying to deactivate is associated with some special settings in Salesforce (like being a default lead or queue owner)? This may take some time as you confirm with business users who the replacement assignee should be. In the meantime, the clock is ticking and you still need to prevent this user from accessing Salesforce. That’s when you can freeze a user’s record, which disables that user’s ability to access Salesforce while you perform related system administrator duties.

To freeze a user, click the Setup link and follow these steps:

1. Click the Users link under the Administer ⇒ Manage Users heading on the sidebar.

   A users list page appears.

2. Click the name of the user you want to freeze.

   The user’s detail page appears.

3. Click the Freeze button.

   You’re returned to the user detail page, and the button name changes to Unfreeze. To unfreeze that user record, click the Unfreeze button.

Setting organization-wide defaults

The organization-wide defaults (OWDs) set the default sharing access that users have to each other’s data. Sharing access determines how data created by users in a certain role or public group is viewed by users within another role or public group. For example, you many want your sales operations team to see the dollar value of won opportunities so that they can verify what was booked versus what’s listed on the signed contract, but you probably don’t want them editing the amount of that won opportunity. If any role or public group possesses data that at least one other role or group shouldn’t see, your sharing model must be private; all other levels of openness must be granted as an exception via groups (more on that later).

No matter which defaults you set to the sharing model, users will still have access to all data owned by or shared with users below them in the role hierarchy.

To configure the organization-wide defaults, click the Setup link and follow these steps:

1. Choose Administer ⇒ Security Controls ⇒ Sharing Settings.

   The Sharing Settings page appears, showing org-wide defaults for several objects, as well as specific sharing rules for those objects.

2. Click the Edit button in the Organization Wide Defaults list.

   The Organization Sharing Edit page appears.

3. Select the desired settings.

   Click some picklists to see the different options. The options are typically Private, Public Read Only, and Public Read/Write. Some objects may have options specific to that object’s functionality, like the Calendar object, and the ability you have to set how much information people can see on others’ calendars. For example, if you want the most restrictive model, choose the following as your defaults: Private for the major records and Hide Details for Calendar. Some standard objects, like the Lead and Case objects, have extra-special powers and have an additional option, Public Read/Write/Transfer. This assumes that someone working heavily in leads or cases will often need to transfer a lead or case record that isn’t owned by him to someone else.

   Remember what we said about role hierarchy providing “vertical access” to data? A Private sharing setting on an object still assumes that people with a role above yours in the role hierarchy can see and report on those records. Salesforce always, by default, respects the hierarchy structure — sharing settings determine only how peers and those outside your typical chain of command see your data. For more complex sharing scenarios, you can have the option to deselect the ability to grant access to records based on role hierarchy, but, you may want to consult with Salesforce support or a Salesforce Partner before making such a complex change.

4. Click Save.

   The Sharing Settings page reappears with your settings listed under the Organization Wide Defaults list.

Granting greater access with sharing rules

By using public groups, roles, or roles and subordinates, you can create sharing rules to extend access above and beyond the organization-wide defaults. For example, if your default sharing model is read-only but you want a group of call center agents to have edit privileges on account records, you could do this with a custom sharing rule.

To add a sharing rule and apply it to your data, click the Setup link and follow these steps:

1. Click the Sharing Settings link under the Administer ⇒ Security Controls heading on the sidebar.

   The Sharing Settings page appears.

2. Scroll down and click the New button next to any of the standard or custom object Sharing Rules lists, as shown in Figure 21-1.

   All lists operate much the same but relate to different records. A Sharing Rule setup page appears for your selected record.

3. Use the drop-down lists to define the data you want to share and the related roles or groups that you want to share that data with, as shown in Figure 21-2.

   For example, you may want to grant your customer support team read/write privileges to account data owned by all internal users. You can apply the sharing rule based on types of users who own the record, or create other filter criteria.

4. Click Save.

   The Sharing Settings page reappears with your new rule listed under the appropriate related list.

When you add a new sharing rule, Salesforce automatically reevaluates the sharing rules to apply the changes to all your records. If your modifications are substantial, you’ll be warned with a dialog box that the operation could take significant time, and Salesforce will email you when complete. When you click OK, the dialog box closes, and the Sharing Settings page reappears. Use the Recalculate button in the appropriate related list to manually apply the changes when you’ve made modifications to groups, roles, or territories.

Reviewing the standard profiles

Most editions of Salesforce come with five or six standard profiles, which can’t be altered except for the tab settings. The number of standard profiles may differ depending on the types of Salesforce licenses your organization has purchased. Newer organizations can stick to standard profiles and address their company’s basic requirements related to user access. If you have Group or Professional Edition, you can’t actually view the settings on the standard profiles.

If you have Enterprise or Unlimited Edition, choose Setup ⇒ Administer ⇒  Manage Users ⇒ Profiles to see your profiles. Otherwise, here’s a brief explanation of the more common standard profiles for Salesforce license types and how they’re typically applied:

• System administrators have full permissions and access across all Salesforce functions that don’t require a separate license. You’d typically grant this level of control only to users administering the system or who play a critical part in configuring and customizing Salesforce.
• Standard users can create and edit most record types, run reports, and view but not modify many areas of the administration setup. If you can’t create custom profiles, you’d probably choose to assign sales reps to the standard user profile.
• Solution managers have all the rights of standard users and can review and publish solutions.
• Marketing users have all the rights of standard users and can perform a variety of marketing-related functions, including importing leads and managing public documents and email templates. If your Salesforce edition has campaigns, marketing users can also administer campaigns.
• Contract managers can add, edit, approve, and activate contracts. They can also delete nonactivated contracts.
• Read only is just what its name implies. Users assigned to this profile can view data and export reports but can’t edit anything.

Profiles never conflict with your organization’s sharing model or role hierarchy. For example, a Standard User profile allows a user to create, edit, or delete leads, but if your sharing model is read-only for leads, the Standard User won’t be able to delete leads owned by others.

Over the years, Salesforce.com has expanded the types of licenses you can buy, to better accommodate your organization’s users and how often and what they need to access in Salesforce. To get the latest comprehensive list with definitions, click the Help link from within any Salesforce page and type license types into the search bar.

Creating custom profiles

If you have Enterprise or Unlimited Edition, you can build custom profiles that provide you greater flexibility than the standard permissions granted to users and the layouts that they see. For example, you may want to create a custom profile for your finance team so that only users with that profile can edit check boxes on the opportunity that track whether certain signed forms have been submitted when you close a deal. See Chapter 17 for details on creating custom layouts and record types.

To create a custom profile, you can start from scratch, but we suggest cloning and modifying an existing profile by following these steps:

1. Choose Setup ⇒ Administer ⇒ Manage Users ⇒ Profiles.

   The User Profiles page appears. You can see which profiles are standard or custom ones based on which ones have the Custom box checked.

2. Click the Standard User link in the Profile Name list.

   The Profile: Standard User page appears. In practice, you can clone from any of the profiles, but by starting from the Standard User profile, you can simply add or remove permissions.

3. Click the Clone button.

   The Clone Profile page appears.

4. Type a title in the Profile Name field and then click Save.

   The Profile page for your new profile appears.

5. Click the Edit button to modify the permissions, as shown in Figure 21-3.

   The Profile Edit page appears.

   Salesforce packs a plethora of possible permissions into a profile page. Some of those permissions aren’t obvious; others are dependent on your selecting other permissions. If you have questions as you’re working through the Profile Edit page, click the Help for This Page link in the upper-right corner of the page to go directly to the relevant Help documentation. If you place your cursor over the i icon, located next to certain Administrative Permissions on the Profile Edit page, rollover text appears with tips on other required settings.

6. Under the Custom App Setting section, determine which standard and custom apps are visible for a profile and which one is the default.

   This determines the content of the Force.com app drop-down list.

7. Under the Tab Settings section, use the drop-down lists to determine the tab settings for your new profile.

   Choose from the three possible options:

   • Default On: You want a tab to be displayed.
   • Default Off: You want a tab not to appear while still allowing a user assigned to the profile the choice to turn the tab back on. For example, if you created a profile for sales reps and you want to hide the Contracts tab but give the rep the option to display it, select Default Off on the Contracts field.
   • Tab Hidden: You want the tab to be hidden without an option for the user to turn the tab back on. For example, if your company isn’t going to use cases, you may decide to hide the tab.

   Making a tab hidden in a user’s profile doesn’t prevent the user from accessing those records (in reports, for example). To prevent a user from accessing a particular type of record altogether, remove the Read permission on that type of data from the Object Permissions sections of the page.

8. (Optional) Select the Overwrite Users’ Personal Tab Customizations check box if you want to overwrite the user’s current personal customization settings with the settings for the new profile that you’re applying.

9. Under the Administrative Permissions header, select or deselect check boxes to modify administrative permissions from the profile.

   Most of these settings are designed for administrators, but some of these may be important, depending on your goals for a custom profile. For example, if you want to build a manager’s profile, you may want to retain permissions such as Manage Public Reports and Manage Public List Views so that managers can create public reports and list views for their teams.

10. Under the General User Permissions header, select or deselect check boxes to modify common user permissions from the profile.

    For example, if you don’t want sales reps to be able to export customer data to a file, you could create a custom profile for reps and remove the Export Reports setting.

11. Under the Standard Object and Custom Object Permissions headers, select or deselect check boxes to modify standard or custom object permissions from the profile.

    For example, if you don’t want support reps to be able to modify opportunities, you could create a custom profile for support reps and select only the Read check box in the row for opportunities.

12. Click Save.

    The Profile page reappears for your new profile. Your new profile will now appear the next time you follow the instructions in Step 1.

13. Click the View Users button if you want to assign users to the profile.

    A Custom: Custom Profile Name list page appears in which you can view, add, or reset passwords for users in the profile.

Setting field-level security

If you have Enterprise or Unlimited Edition, you have three primary ways to control access to and editing of specific fields: profiles (which we discuss earlier in this chapter), page layouts (Chapter 17 covers these), and field-level settings (stay right here for the details). With field-level security, you can further restrict users’ access to fields by setting whether those fields are visible, editable, or read-only.

To view and administer field-level security, click the Setup link and follow these steps:

1. Choose Administer ⇒ Security Controls ⇒ Field Accessibility.

   The Field Accessibility page appears, listing all objects.

2. Click the link for the type of record for which you want to view and manage field-level security.

   A Field Accessibility page for the selected record type appears, as shown in Figure 21-6. For example, click the Account link if you want to review the security settings on account fields.

3. Under the Choose Your View header, click the View by Fields link.

   The Field Accessibility page appears with a Field drop-down list. If you want to see a different view of this information — in which you get to see one profile and the security levels for all the fields for the selected data type — click the View by Profiles link.

4. Select a field from the Field drop-down list.

   The page reappears with a table displaying your company’s profiles and the profiles’ accessibility to the selected field.

5. In the Field Accessibility table, click a link in a cell in the Field Access column to edit the profile’s field access for a specific record type.

   An Access Settings page for the selected profile and selected field appears, as shown in Figure 21-7. If you want to modify access for all profiles associated with the page layout assigned to this profile, you can also adjust that here.

6. Select the check boxes to modify the field-level settings, and then click Save.

   The Field Accessibility page for the selected record type reappears.

If you modify a field-level security setting for a profile by deselecting the Visible check box, this means that the record related to that field is still searchable. The field will never be viewable to a person with that profile, so that person won’t be able to create reports or search using it, but he can use reports created by others that leverage that field. So, if an account — say, ABC Corp. — had its Employees field filled out with the number 1001, but that field was not visible to Watson, who has the Standard User profile, Watson could still run a report created by Holmes, who, with a different profile, was able to customize a report looking for all accounts where the Employees field was greater than 1000. In that report, ABC Corp. would be listed and Watson would see ABC Corp., but he would not see the Employees field in the output. Watson would also not be able to customize a report using the Employees field because he can’t see it to modify a query.

If you need to provide someone with similar access to records as an existing user, with the exception of visibility to a few fields, we recommend that you do this via field-level security on a new custom profile, versus removing the field from the page layout. It may not be visible on a page, but that field is still visible elsewhere in Salesforce — like when creating and running reports and list views. Even if you’re not strict about a group of people not seeing a field, field-level security can help reduce end-users seeing an overwhelming number of fields that they have to wade through when creating reports.

Delegating administration

As an administrator for your growing world of Salesforce users within your company, you hold the key to who accesses your Salesforce instance. You shouldn’t try to cut corners by making everyone system administrators just because you’re annoyed each time people bug you to add a new user, or because they get impatient about your asking “Why?” in response to their requests.

Salesforce allows you to delegate some administrative duties to nonadministrators. Delegated administrators can help you create and edit users in roles you specify, reset passwords for those users, assign users to certain profiles, and manage certain custom objects. For example, if your marketing department is growing quickly, you may want to allow a manager in the Marketing Manager role to add new marketing users to Salesforce who need the Marketing User profile.

With more users and different groups that need access to the same object, be cautious in granting delegated administration permissions to users for specific custom objects. Usually this will result in changes being made that benefit one group at the expense of another, and you’re left to diplomatically mend strained relationships. It’s your responsibility as a system administrator to have a holistic understanding of how system changes will affect all your users.

To delegate administration, you must first define the groups of users to whom you want to delegate these new privileges. Then you have to specify what you want those newly delegated administrators to do. To define delegated administrators, follow these steps:

1. Choose Setup ⇒ Administer ⇒ Security Controls ⇒ Delegated Administration.

   The Manage Delegated Groups page appears.

2. Click New.

   The Edit Delegated Group page for the new delegated group appears.

3. Enter the Delegated Group Name.

   In our example, we selected Sales Operations.

4. Click Save.

   The Delegated Group page for your new group appears.

5. Click the Add button in the Delegated Administrators related list to specify which users will belong in this group.

   The Delegated Administrators page appears.

6. Use the Lookup icons to find and add users to this group.

7. Click Save.

   The Delegated Group page for your group reappears.

8. To specify which roles and subordinate roles a delegated administrator can manage, click the Add button in the User Administration related list.

   The Roles and Subordinates page appears.

9. Use the Lookup icons to find and add roles that your delegated group may manage.

10. Click Save.

    The Delegated Group page for your group reappears.

11. Click Add in the Assignable Profiles related list to specify which profiles these delegated administrators may assign to users.

    The Assignable Profiles page appears.

12. Use the Lookup icons to find and add profiles that your delegated group may assign.

13. Click Save.

    The Delegated Group page for your group reappears.

14. Click Add in the Custom Object Administration related list to specify which custom objects and related tabs a delegated administrator may manage.

    The Custom Object Administration page appears.

15. Use the Lookup icons to find and add custom objects that your delegated group may assign.

16. Click Save.

    The Delegated Group page for your group reappears.