-
Notifications
You must be signed in to change notification settings - Fork 19
Implementation FAQs
- General FAQs
-
Installation and Setup FAQs
- How do I install Interactions?
- Can I Install Interactions in a Developer or Sandbox org?
- Can I install Interactions into an org that has the Nonprofit Success Pack (NPSP)?
- How customizable is the Interactions Package?
- Do I have to use the Interactions app?
- If I don’t want to use certain fields or objects, can I remove them?
- Interactions doesn’t have some of the fields or objects our organization needs. Can we add them?
- Can I customize the Opportunity Stages?
- How do I ensure users only see the data they should?
- Integration FAQs
-
Architecture and Data FAQs
- Why does Interactions use EDA instead of all custom objects and processes?
- What are Interaction Mappings used for?
- What is the difference between Recruitment Interest and Academic Interest?
- What are the Campaign and Additional Campaign fields on Interaction used for?
- How does Interactions prevent duplicates?
- What is re-processing?
Yes. It is expected you will use Lightning, but it is not required. The provided App is a Lightning Console app, but everything can be done in Classic as well.
For the standard Interactions package – yes, EDA must be installed first. Interactions leverages the EDA One-to-one Contact to Account model and Affiliations, Terms, and EDA Account record types. Interactions can be used without EDA, but the open-source code must be downloaded and edited by a developer to remove references to EDA fields and objects first.
Interactions does not support Person Accounts, but you can install it in an org with Person Accounts enabled.
Our Salesforce org is highly-customized with objects, packages, apps, and code. Can we use Interactions?
Yes. Since it is implemented as an unmanaged package or by using the open-source code on GitHub, it can be customized to work in most orgs. We recommend reading through the Installation & Configuration Guide as well as having a developer look through the Technical Implementation Guide to determine if it fits in your existing org.
Go to the Interactions for Student Recruitment GitHub page and click on the “Install in a Sandbox” or “Install in a Production or Developer Org” links in the ReadMe file. Then, follow the instructions in our Installation & Configuration Guide.
Yes – if EDA is installed first, the standard Interactions package can be installed in a Production, Developer, or Sandbox org. If you are not using EDA, you can still install Interactions in any of these orgs, but you will need to modify the package in GitHub to remove any reference to EDA objects first.
Because Interactions for Student Recruitment uses the Education Data Architecture (EDA) as a base, it is not recommended to install Interactions and NPSP in the same org. See the EDA FAQ page for this recommendation.
The package is unmanaged, and the open-source code is available on GitHub, so it is very customizable and open to community collaboration! View the Interactions for Student Recruitment GitHub repository and Power of Us Chatter Group for the Interactions Package.
No. You can add the tabs you need to one of your existing apps or create a new custom app. Remember, because this is an unmanaged package, you can also edit the Interactions app that comes out-of-the-box to match your recruitment processes.
Yes. This package is unmanaged, and any fields or objects that do not directly reference EDA can be deleted or edited. Please read all the provided Interactions documentation before removing or editing fields to be certain you understand how those changes will affect the processes.
Yes. To add fields, just create the fields on the desired object as well as the Interactions object, then create the applicable Interaction Mapping records to connect them. Adding objects will require additional Apex coding. See the Technical Implementation Guide for more information.
Yes. The Opportunity Pipeline at both the Inquiry and Applicant level is fully customizable to match your recruitment business processes. Additionally, moving through these stages can be manual, automated (usually via integration) or a combination of the two!
Interactions is built inside of Salesforce, which has a very robust security model. Interactions will respect all Salesforce security and sharing settings. For more information on Salesforce security, see the Salesforce documentation covering this subject, beginning with this Field-Level Security article.
Yes. Interactions will run in bulk. You can load data using Data Loader, Dataloader.io, Data Import Wizard, an existing solution available in the marketplace, or through a custom solution that connects with the Salesforce SOAP or REST APIs. We recommend testing in a sandbox first and cleaning the data prior to a load as much as possible. Please note that loading times will depend on any customizations that are made to the Interactions package as well as any preexisting Apex code, workflow, or other processes in your org.
Yes. Interactions includes a unique external ID field called Constituent ID on the Lead, Contact, and Interaction objects you can use to store an ID from your SIS. This field is used in the basic duplicate management rules for matching records. You can bulk load data into Salesforce from your SIS like any other list load with the Interaction Source of “Student Information System” to track where this data came from for reporting and auditing.
Salesforce.org developed the Education Data Architecture (EDA) to provide a foundation for higher education using information gathered from their customers and industry leaders. This architecture includes objects and fields that are important to institutions as well as processes to manage the structure of the data, such as the “One to One” Account model. Rather than reinventing the wheel, Interactions leverages existing functionality offered by Salesforce wherever possible, including features such as Duplicate Management. This will also allow you to take advantage of updates from Salesforce as these features are expanded.
The Interactions process was built to be click-configurable where possible to make it more manageable without sacrificing performance. Interaction Mappings allow you to add, edit, or delete mapped fields involved in the Interaction process without editing the Apex code. Read more about Interaction Mappings in the Technical Implementation Guide and the Installation & Configuration Guide.
Institutions often use general degrees for recruiting and marketing, but offer more specific degrees upon application, or as a declared major after enrollment. For example, a new inquiry may say they are interested in Accounting, but the academic degrees offered in this area include BBA, BSBA, and a special accelerated track. The custom object, Plans, in the Interactions package includes a Type field for differentiating between these marketing values and the actual degrees being offered (called Recruitment Interest and Academic Interest, respectively).
Campaigns are a standard Salesforce object that can be used to track events, communication, or marketing efforts that influence a Lead, Contact, or Opportunity. The Campaign field on Interaction can be used to track the way data was received, such as at a specific event or tour. The Additional Campaign field on Interaction can be used to track data related to a specific marketing effort, such as an email blast that invited the individual to an event, or a flyer that encouraged them to sign up for a tour. The way these fields are used and campaigns are organized is entirely up to you. Both will result in the creation of a Campaign Member for that individual.
Interactions leverages standard Salesforce Duplicate Management functionality to reduce the possibility of duplicates. However, this method of duplicate prevention will depend on how you have designed your matching rules and how clean your data is. We recommend you test in a sandbox first, and always employ other methods of data cleansing before and after loading data into the system.
By setting an Interaction’s status back to “New” from “Imported” or “Audit Required” and clicking Save, the Interaction Processor (code) runs for that Interaction as if it is a brand new record. Re-processing is primarily used in the moment to solve a manually-inputted error or when resolving “Audit Required” Interactions. Read the re-processing section of the Interactions User Guide for more information on re-processing Interactions.