Skip to content

Discovery

Jump to bottom
Kara McIntyre edited this page May 31, 2019 · 1 revision

Table of Contents

Purpose and Project Objectives

The purpose of this document is to guide administrators through the process of determining the level of effort that will be needed in order to implement Interactions for Student Recruitment in an existing org. It includes questions pertaining to the current org's setup and business requirements, how to translate these into Interactions for Student Recruitment, and what types of resources will be needed based on the answers to the previous questions.

The goal of this project should be to enhance your University's recruiting experience, particularly for administrators and end users. Additionally, it is extremely helpful for data loading and integrations by funneling data through a single object (Interactions) while the custom code (along with Interaction Mappings) does the hard work for you.

Review Interactions for Student Recruitment

Before delving into the discovery process of Interactions for Student Recruitment, it is extremely important that you understand how the data model is setup, how it works with EDA, and how the Interactions custom code functions. This understanding will help you to determine, via the discovery process, the level of effort for installing Interactions for Student Recruitment. Whether it is simply downloading the package from the link or recruiting a developer to dive into the code, it is crucial for your success to fully understand Interactions for Student Recruitment before implementing it.

Here is the link to the GitHub repository for Interactions for Student Recruitment, there you will find the Interactions custom code as well as all of the documentation pertaining to the package.

For additional information or to connect with the community about Interactions for Student Recruitment, please join the chatter group in the Power of Us Hub.

Discovery Questions

The following questions provide a starting point for discussions around how recruitment is currently done, what needs to happen in the future, and how this project should be managed. The "How Are Things Done Now" section is numbered, and each set of questions maps to its same number in the "Moving Forward, How Should They Be Done" section. Additional questions should be added to each section as needed.

How Are Things Done Now?

  1. What type of recruiting do you do? Centralized, decentralized, or both? What defines a unique recruitment record (ex: If two records are for the same student, academic level, and term, are they considered the same record regardless of any other data)?

  2. What defines a unique individual (ex: If two records have the same first name, last name, and email, are they considered the same record regardless of any other data)?

  3. What information do you collect? Where does your data come from? How is the data structured? If you already have a Salesforce org, do you use EDA?

  4. What setup data do you store or collect? (ex: terms, plans or programs of interest, educational institutions, business organizations, etc.)

  5. What do you currently report on?

  6. What is your current security model? Can different groups see each other’s data? Is security based on department ownership or the user's job functions?

  7. What are some typical use cases for your organization? What are your pain points?

Moving Forward, How Should They Be Done?

  1. Does the Opportunity Key fit your recruitment process? If not, how does it need to be customized?
  1. What, if any, changes need to be made to Salesforce matching rules to minimize the creation of duplicate records for individuals?
  1. Where will your data come from? What information do you need to collect? How will your current data model map to the EDA and Interactions data models? Will you use EDA?
  1. What setup data do you need in Salesforce? What additional data do you need to collect for these records?
  1. What reports and dashboards do you need? What additional fields do they depend on that are not currently in the package?
  1. Do you need an open or closed security model? Will departments be able to see each other’s data? Will access be based on the department a user is in, or their job functions?
  1. What are the main use cases that must be delivered? What functionality do you need that has not yet been discussed?
  • Create UAT and training plan
  • Review all functionality described in the User Guide
Clone this wiki locally