Profiles are set up to determine or limit the range of CRM permissions, access, and activities. For example, an admissions counselor would not need the same permissions and access as a CRM administrator.
Page layouts set which fields are visible, read-only, or required on detail and edit pages.
Record types specify which subset of picklists defined for a record type is visible to a user based on their Profile.
Field-level security can be set for specific profiles or specific fields across all profiles.
A Salesforce ID is a system-generated, case-sensitive string of 15 or 18 letters and numbers uniquely identifying each Salesforce record. The 18-character Salesforce ID can be safely compared for uniqueness by case-insensitive applications.
Within the CRM, the 15-character ID can be found in the URL for the record or by selecting it for display in a report. The report data can be exported as an Excel or CSV file for later use in a data updating procedure. The Apex Data Loader can also extract record data, including the Salesforce ID.
You will need the Salesforce ID for the updated records via the Apex Data Loader when using the update or upsert commands or when loading related list data items. For the Student record, examples of related list items could be Family Relationships, Enrollment History, and Tests. The Salesforce ID of the Student record being updated is required to establish the proper relationship between the student and, for example, the Test record being created or updated.
An external ID is a custom field that has the "External ID" attribute, meaning that it contains unique record identifiers from a system outside of Salesforce. External IDs can be used instead of a Salesforce ID in the Apex Data Loader.
A Master-Detail Relationship occurs when you have a one (Master) to many (Detail) situation. For example, you may have one student who has multiple Applications. You can create a relationship where the Student object is the Master, and the Application object is the detail.
Once this relationship is created and the Master object page layout is updated, you can view Detail-related data on the Master object.
The following are considerations for Master-Detail Relationships:
The major difference between the two relationships is the impact on the data hierarchy. In a Master-Detail Relationship, the detail records have a direct relationship and will be deleted if the master record is deleted. Only the relationship is lost if a record is deleted in a Lookup Relationship.
Another key differentiator is the inability to create Roll-Up Summary fields in a Lookup Relationship. These data types can only be used in a Master-Detail Relationship.
Before building any relationship between objects, think carefully about the reason for creating such a relationship. Master-detail relationships can give you more flexibility in reporting on the data, but they are harder to change once the relationship is established. Lookup Relationships may give you more flexibility from a design standpoint but do not give you the same reporting options.
In the Recruitment Manager, a combination of the following components and functionality translates into what is commonly referred to as a "Communication Plan":
CRM Email Campaigns – Rules and Templates CRM Letter Campaigns (via Conga) – Rules and TemplatesA Rule (primary purposes):
Defines the criteria used to select the desired population to receive the communication. Defines the related Template that will be used to generate this communication. Defines the schedule when the CRM will select this desired population and deliver the communication.
A Template:
Combined, the Rules and Templates for Email Campaigns and Letter Campaigns create a "Communication Plan."
Salesforce provides an Application Programming Interface (API) to allow third-party applications to exchange data with their platform. Many CRM applications (Email, Events, Informatica, DemandTools) utilize the API to create a seamless experience for the user. Because the CRM runs on a multi-tenant platform, Salesforce needs to ensure resources are available on demand for all users. To achieve this, Salesforce budgets 1,000 API calls per user during a rolling 24-hour period. Any number of users can utilize API calls, but no user can exceed the aggregate. For example, if your organization has 30 users, then 30,000 API calls are budgeted in a 24-hour period for all users.
You can be notified before reaching your API limit. To set up a notification, go to [Your Name] > Setup and search for API Usage Notifications. Click New.
Enter a Salesforce user notification recipient, threshold percentage, and notification frequency. Click Save when complete.
There are two data storage limits – Data and File Space. Data space is storage for all records stored in the system, while data space is files attached to records or documents stored in the documents area.
Each Salesforce account is allocated a minimum of 1 Gigabyte of data space or 50 Megabytes per user, whichever is greater. 10 Gigabytes or 512 Megabytes per user, whichever is greater, of file space, are allocated for each account.
You can see your current space usage by going to Setup and searching for Company Information. You can click "View" to see additional details. There is no way to be notified when your storage limits reach a threshold near the maximum.
The Unknown School acts as a placeholder in the CRM for student records that do not have a school associated with them. This also allows you to easily track all the students missing this vital information.
The CRM data hierarchy works best if students are attached to school records. All of the CRM Reports are based on students attached to schools, and any students not attached to a school record will not be included in the report.
Student Inquiry & Event Registration data will be viewable in the CRM immediately.
Application: If a student is applying through the online application system, the data they have entered will become available in the CRM after the next scheduled synchronization between the application database and the CRM runs. Contact Support to find out when your specific synchronization runs.
The student and application data share a master-detail relationship (see Overview of Object Relationships for more information). The detail object is also referred to as a child object. The Student (Contact) object is the Master, and the Application object is the detail/child.
The nature of the relationship is described on the detail object. The relationship is defined within the context of the custom field named Contact on the Application object. You can see in the field information right-hand column that the Data Type is listed as "Master-Detail." The Sharing Rule states that if you have Read/Write permissions on the student (Master) record, you can create, edit, or delete related Application (detail) records.
It is important to note that when you delete a master record, you also delete all its detail records. So if you delete a Student record, you are also deleting any Application, Enrollment History, Test, etc. records that exist for that student because they are all detailed records. Undeleting the student (Master) record also undeletes detail records.
Fields installed as part of a managed package are called managed fields. The main advantage of installing a managed package is that upgrades are considered "non-intrusive" and can be done while users are logged in to the application. However, there are restrictions on fields that are a part of a managed package. One such restriction is the inability to change a label on a managed field.
To determine if a field is a managed field, go to [Your Name] > Setup and select Object Manager > [Object Name]
Look in the Custom Fields & Relationships section.
If there is a white icon with a blue "down" arrow next to the field, it means the field is managed.
Note: If the managed field does not do what you need, create a new custom field and replace the managed field on the page layout with your new field.
Picklist, multi-value picklist and boolean-type fields can be set to conditionally display values based on selection in controlling fields.
To create a dependent picklist for standard objects, go to [Your Name] > Setup and select Object Manager > [Object Name].
To create a dependent picklist for custom objects, go to [Your Name] > Setup and select Object Manager > [Object Name]
Standard objects are database tables included with the Salesforce platform. While there are numerous standard objects, the most visible and used objects in CRM are the Account and Contact objects. Both of these objects are renamed Schools and Students.
Like standard objects, standard fields are included in the platform and part of Salesforce standard objects. While some types of standard fields can be customized, most cannot.
Custom objects are database tables that allow you to store information unique to your organization. We have included several custom objects for managing data specific to the recruitment process. Included with a CRM installation are Applications, Tests, Enrollment History, Family Relationships, Extra-Curricular Activities, Essays and Recommendations, and Financial Aid. Other applications for the Salesforce platform will use their own set of custom objects.
Custom fields can be created on either standard or custom objects to increase the number of data fields managed for a record. There are numerous types of custom fields, but many are analogous to the field types expected in any database management system. The Salesforce platform includes some special field types. For example:
To add or update values to pick list fields, follow the below steps.
Note: When adding new values to any field, you will see a checkbox option to apply the values to specific Record Types, which may be required if you restrict picklist values based on Record Types.
If you do not add the field's new values to a specific Record Type upon creation and need to do so later, you can do so by following the steps below.
To add fields to be available for use on a specific report type, follow the steps outlined below:
Note: You cannot change standard Salesforce or custom TargetX-delivered report types. To customize these report types, you must recreate them as custom report types.
The Salesforce platform provides a security model at the field level. There are several factors that determine if a field can be viewed or edited by a user.
Page Layouts - You can set whether fields are visible, required, editable, or read-only.
Field-Level Security - You can further restrict users' access to fields by setting whether those fields are visible, editable, or read-only. These settings override any field properties in the page layout if the field-level security setting is more restrictive.
Permissions on profiles -Some user permissions override page layouts and field-level security settings. For example, users with the "Edit Read Only Fields" permission can always edit read-only fields regardless of other settings. Note that the field accessibility grid includes any field access restrictions based on permission.
Universally required fields - Certain custom fields can be made widely required, overriding any less-restrictive settings on page layouts or field-level security. Making a field universally needed gives you more data quality beyond the presentation level of page layouts. Universally required field settings apply to the platform's user interface, API, and other connection tools. The following field types can be set with universally required settings: Currency, Date, Date/Time, Email, Master-Detail Relationship, Number, Percent, Phone, Text, Text Area, and URL.
For standard objects, navigate to the customize section under Setup, then select the page layouts section for the Object.
For custom objects:
Field-level security can be set for each user profile defined in the system. Select "Visible" to allow a user profile to view and edit the field. Check "Read-only" to allow a user profile to view the field.
A security token is an authentication key that allows a Salesforce account holder to access Salesforce data through the remote API.
There is no way in Salesforce to retrieve your security token. If you need it and don't know its current value, you'll need to reset it.
Resetting Security Token:
Permissions are set on the Profile. For each Profile you want to give Full access, be sure the following items are selected:
Schedule Dashboards Manage Dashboards Manage Dynamic Dashboards Drag-and-Drop Dashboard Builder View My Team's DashboardsThis link to Salesforce Help & Training may also be helpful as it outlines permission details.