TaroWorks Implementation Guide November 2015
Welcome to TaroWorks! We’re excited to have you on board, and we expect that you’re excited about launching TaroWorks in the field. This implementation guide is designed to help you launch TaroWorks, so you can start using data to make more informed decisions for your organization and better drive your processes in the field. You may have completed your TaroWorks evaluation, in which case you already have a survey in place. This implementation guide will help you get the rest of the system up and running so you’re able to see results as data comes back into Salesforce.
If you have not done an evaluation, this guide will help you through the implementation process from beginning to end! As you can imagine, there is a considerable Salesforce component to launching TaroWorks. This guide will help you frame your approach for using Salesforce for TaroWorks. Where available, we’ve included links to additional resources. As you walk through this guide, if you have any questions, you have several options available to you:
• Search for articles in our Customer Support Site. • Search for video tutorials in our YouTube channel. • Reach out to your account representative. • If your question cannot be answered in the above channels, email a support ticket to
[email protected].
TaroWorks Implementation Guide
2
Table of Contents
System Requirements
TaroWorks / Salesforce Overview
Deployment Roadmap and Timeline •
Phase 1: Define Business Objectives
•
Phase 2: Configure Data Model
•
Phase 3: Create Jobs and Surveys
•
Phase 4: Deploy
•
Phase 5: Maintenance
TaroWorks Implementation Guide
3
System Requirements SYSTEM REQUIREMENTS
See the links below to set up your Salesforce instance and Android devices. •
System Requirements
•
Technical Requirements
TaroWorks Implementation Guide
4
Salesforce Overview SALESFORCE OVERVIEW
Database hosted in the cloud
Began as a Customer Relationship Management system
Extremely flexible and allows for expansion
Main benefits:
Highly customizable
Click and Drag Reporting
Powerful yet easy to use
No infrastructure investment needed
Backed-up and secure
Ability to add extensions to enable complex operations
TaroWorks Implementation Guide
5
TaroWorks/Salesforce Overview TaroWorks Surveys •--------•--------•--------•---------
Salesforce
Surveys •--------•--------•--------•---------
Reports and Dashboards
Your field information is initially collected using the TaroWorks mobile application. Once you sync TaroWorks, the data from the field is loaded into the Salesforce database where you can analyze your data using reports and dashboards. The best way to set up TaroWorks/Salesforce is to start with your reporting goals and objectives to inform the design of the Salesforce database and TaroWorks surveys. TaroWorks Implementation Guide
6
Deployment Roadmap Overview 1. Define Business Objectives What reports do you want? What type of data do you need?
2. Configure Data Model How to store your data. Setting up Salesforce.
3. Configure Jobs and Surveys Connecting to Salesforce. Building TaroWorks Jobs.
4. Deploy Collecting your data in the field.
5. Ongoing maintenance Keeping things running smoothly. TaroWorks Implementation Guide
7
Deployment Roadmap Overview 1. Define Business Objectives What reports do you want? What type of data do you need?
2. Configure Data Model How to store your data. Setting up Salesforce.
3. Configure Jobs and Surveys Connecting to Salesforce. Building TaroWorks jobs.
4. Deploy Collecting your data in the field.
5. Ongoing maintenance Keeping things running smoothly TaroWorks Implementation Guide
8
Deployment Roadmap Details 1. Define Business Objectives Objectives
Reports
Project staffing
Stakeholders
Workflows
2. Configure Data Model Objects
Fields
Relationships
3. Configure Jobs and Surveys Surveys
Jobs
Reports and Dashboards
Migrate Data
4. Deploy User Setup
Training
Create reports
Create dashboards
5. Ongoing Maintenance Maintenance best practices TaroWorks Implementation Guide
Ongoing iteration
9
Deployment Roadmap Details 1. Define Business Objectives Objectives
Reports
Project staffing
Stakeholders
Workflows
2. Configure Data Model Objects
Fields
Relationships
3. Configure Jobs and Surveys Surveys
Jobs
Reports and Dashboards
Migrate Data
4. Deploy User Setup
Training
Create reports
Create dashboards
5. Ongoing Maintenance Maintenance best practices TaroWorks Implementation Guide
Ongoing iteration
10
Implementation Timeline Task
Wk 1
Define Goals, Reports and Dashboards
X
Define Processes
X
Create Objects and Fields
X
Wk Wk 2 3
Create Jobs and Surveys
X
Testing
X
Create Reports and Dashboards
X
Migrate Any Existing Data
X
Create Users
X
Wk 4
(Mobile Record Assignments, Performance)
Train Field Staff
X
Pilot Jobs
X
Incorporate Feedback from the Field
X
LAUNCH! TaroWorks Implementation Guide
11
Introduction to Aquacomb To bring the deployment process to life, we’re going to use the example of a fictional social enterprise, Aquacomb, to illustrate how they deploy TaroWorks. You’ll learn more about Aquacomb throughout this guide, but here’s a summary about them. Throughout the guide, Aquacomb examples will be in purple boxes. Aquacomb Example What Aquacomb does Aquacomb is a social enterprise that builds wells and sells water filters. They engage in a number of activities: • Assess potential well sites. For approved well sites, they build wells and monitor the progress of the construction projects. • Sell water filters. They currently sell water filter in two sizes – large and small. • Register the people (well site members) who go to their wells or buy filters, and check up on them over time to track their health outcomes and poverty rates.
Where Aquacomb operates Aquacomb operates in 4 geographic locations: Amber City East, Amber City West, Brasstown, and Carrotville. How Aquacomb will conduct these activities Aquacomb employs mobile users who do everything from assess the well sites, to selling water filters, to registering customers, to conducting check-in surveys with their customers over time. They have already decided to manage all of these processes using TaroWorks and Salesforce, and are ready to launch so their mobile users can start using this tool as soon as possible. TaroWorks Implementation Guide
12
1. Define Business Objectives
Phase 1: Define Business Objectives This section will help you define the goals for your TaroWorks implementation.
Salesforce also has an effective worksheet for determining goals for a Salesforce implementation: Getting Started Implementation Guide Since Salesforce is critical to a successful TaroWorks implementation, please take time to review the Salesforce worksheet. Phase 1 Checklist: By the time you have completed this phase, you will be able to:
Describe the business process that you want your field team to carry out and how they support the objectives of your operation as a whole.
Confirm which key metrics you want reports for and how they should be presented.
Identify who in your organization will be responsible for which part of the implementation and gaps in staffing, if any.
Know how best to measure the impact of implementing TaroWorks.
TaroWorks Implementation Guide
14
Project Staffing In order to ensure successful deployment and adoption of TaroWorks, it is essential that you are staffed with appropriate resources. It may be that certain individuals comprise several roles. The required roles are: 1.
Executive Sponsor - lends influence to the project by becoming the champion, and sets the business vision for the deployment.
2.
TaroWorks Lead - manages the entire TaroWorks deployment process and ongoing use, and be the point-person for interactions with the TaroWorks team.
3.
Survey Lead - manages the survey design, and determine the desired reports from the incoming data for various stakeholders to monitor and evaluate.
4.
Technical Lead - manages ongoing Salesforce.com administration and mobile device troubleshooting. Technical issues from the field may be escalated to this person.
5.
Field Staff Manager - oversees the roll-out to field staff, and be the point-person for day-to-day questions about the mobile devices.
6.
Field Staff - who will use Androids with TaroWorks in the field for data collection and performing jobs.
Best Practice We’ve seen that including these roles as part of job descriptions has helped clients deploy TaroWorks faster, and see faster adoption of the technology. TaroWorks Implementation Guide
15
Stakeholder Objectives The power of TaroWorks is its ability to benefit stakeholders across the organization. Think about the objectives for each of your stakeholders and their individual needs. 4 typical stakeholders may include: Stakeholder
Role
Executive
• Concerned with the big picture, making sure that the organization is serving its customers effectively and efficiently • Needs timely information to monitor progress and document impact to funders
Technology Manager
• Responsible for leveraging right tools for processes to do their job efficiently
Business / Sales / Program Managers
• Responsible for defining field staff activities and making sure that those activities are contributing to the mission
Mobile Users
• Responsible for carrying out essential activities that deliver value to your clients
In the next few pages, obtain the objectives from each of these stakeholders’ perspectives. Have a conversation with them about their goals, or put yourself in their shoes.
TaroWorks Implementation Guide
16
Objectives Executive Guiding Questions
What are your key strategic goals for the next 12 months?
How will TaroWorks help you achieve these goals?
What decisions do you wish to make with this information?
What are the objectives of your business/program? What is success?
What kind of information do you need to become successful?
Where will that information come from?
Example Objectives What does the executive team hope to get out of TaroWorks?
• Identify top customers • Show reports to donors • Better communication both internally and externally • Track overall impact and performance • Validate business strategies, and have data for pivoting. • Target the right group (i.e. the poorest)
How are these goals measured?
• Dashboard to highlight top customers • Dashboard to highlight change over time of performance/impact/PPI • Dashboard comparing performance of different business strategies • Dashboard of poverty rates using the PPI
TaroWorks Implementation Guide
17
Objectives Technology Manager Guiding Questions
What are your goals for the next 12 months?
How will TaroWorks help you achieve these goals?
What decisions do you wish to make with this information?
What kind of information do you need to become successful?
Where will that information come from?
Example Objectives What does the technology team hope to get out of TaroWorks?
• • • •
How are these goals measured?
• Dashboards displaying usage level for each user • Time saved from streamlined data collection
TaroWorks Implementation Guide
Better data quality, and less time validating data Broad user adoption Streamlined reporting Less time working between different platforms
18
Objectives Business/Sales/Program Managers Guiding Questions
What are your goals for the next 12 months?
How will TaroWorks help you achieve these goals?
What decisions do you wish to make with this information?
What kind of information do you need to become successful?
Where will that information come from?
Example Objectives What does the business/sales/program manager hope to get out of TaroWorks?
• • • • • •
How are these goals measured?
• Dashboards of activities, and activities per mobile user • Dashboards of activities by region or other categories • All leads are tracked in Salesforce • Dashboard of poverty rates using the PPI
TaroWorks Implementation Guide
Identify top mobile users Find ways to incent mobile users Capture registrations/transactions Identify areas for improvement in processes Get faster visibility into progress in the field Target the right group
19
Objectives Mobile Users Guiding Questions
What tools would help you complete your activities more effectively?
What information do you need to be more effective in the field?
Example Objectives What do the mobile users hope to get out of TaroWorks?
• • • • •
How are these goals measured?
• Dashboard of performance against jobs and peers
TaroWorks Implementation Guide
Work offline Get credit for work Visibility into previously collected information Visibility into their own portfolio of clients Their progress against goals
20
Outcomes / Reports
From your objectives: What kind of information do you need to be successful?
Do you currently use any reports that contain this information? Are you planning any of these reports?
What indicators will you need to track? What will you need to track daily/weekly/monthly?
Who will use this information? What will they do with it?
How do you and others at the organization need to see your information? (i.e. client profiles, aggregated in charts, CSV files?)
Are you looking to measure impact1 at your organization?
Aquacomb Example • The executive would like to analyze regional performance to see which regions need additional interventions • Program managers want to know their region’s high performing mobile users • Program managers want to know if there is a link between members’ visits to the well and their health outcomes (# of sick days) • Mobile users want to understand the poverty rate profile of their well site members for targeted intervention
: See appendix Measuring Impact for more information TaroWorks Implementation Guide 1
21
Processes in the field Processes:
A process is a sequence of actions that your mobile users do in support of your operations. Examples - mobile users registering farmers, technicians inspecting a well, agents logging a sale, or trainers providing a workshop to community members. Even without a formal flowchart, examining your existing forms and interviewing your staff can help you define these processes. TaroWorks is built so you can digitize these processes into Jobs that mobile users can do from their Android devices. Jobs are made up of Tasks. Tasks are the sequential steps that make up a job - ensuring mobile users follow a standard operating procedure.
Questions: • •
What is the most common process for your mobile users? \What are some other processes that they follow in the field?
TaroWorks Implementation Guide
22
To Do: Mapping your Processes
Guiding Questions: Even for the least complex processes, we recommend drawing out and validating these steps before attempting to build them into TaroWorks. • What are the different things that your mobile users are responsible for, starting with the most common one? • Where are they doing this work? • How often are they doing this work? • With who or what would your mobile users interact with? • What is the standard way to identify who / what you are interacting with? • Would the mobile user need to review any previous information? • Which form should the field office collect information with? • What should happen next time you visit that person or object? • How would performance be monitored and incentivized? TaroWorks Implementation Guide
23
To Do: Mapping your Processes Aquacomb Example As mentioned before, Aquacomb has three main operations: Assess potential well sites and build on approved sites; Register well site members into the system then track members’ welfare over time; Sell members filters. Breaking down these operations into process segments we have: • Assess a Well Site in the assigned region and create record in the system • For sites approved by headquarters, track construction progress until completion • Register members using a particular well • Regular visits to registered well site members • Sell water filters to well site members Now let us drill down into just the workflow where the mobile user conducts his/her monthly visits to each well site member: Description of process: As a Mobile User, I visit a region, go to a well site, and visit a well site member every month. With the well site member, I conduct a monthly check-in, using paper surveys to collect the latest information (i.e. # of well visits, # of sick days, picture, GPS coordinates, signature, and notes for my next visit), and provide them with relevant training. What is the activity: Mobile User’s monthly check-in with well site member Who is involved: Mobile Users and well site members How often: Monthly check up Data Collected: # of times a well site member visit a well, # of sick days a well member had in the month, GPS coordinates of the well, signature of well site member, income of well site member, poverty indicators for well site member, and general notes on conditions Record Hierarchy
Region
Well
TaroWorks Implementation Guide
Member
Conduct monthly check-in
24
Putting it together With a holistic view of your objectives, goals, and processes outlined, you’re ready to analyze what you’ll need to collect with TaroWorks: what levels of data are necessary, what data will be used for (i.e. reports, analysis, or general information), and how often it’s collected? Defining these parameters will directly influence how you set up Salesforce (build your data model) in the upcoming Salesforce configuration phase.
Levels of information needed What are the different levels or entities that you would need to collect information on? Example: An executive needs overall business information across all regions, while a field manager may need information for one particular region. Different entities What are the different “things” for which you want to collect information? These entities could be regions, hives, farms, farmers, households, trees, countries, etc. Note how these entities might be related to each other, i.e. trees will always be related to a farm, a region is always a subset of the entire business, a list of states isn’t related to anything else, etc. Logging new records / updating records Do you need to capture historical information for these entities (i.e. a patient’s health status)? Is there a recurring workflow where mobile users are collecting the same information? Or do you just need to know the most current information, such as the patient’s current address, and historical information is not necessary?
TaroWorks Implementation Guide
25
Putting it together Aquacomb Example Aquacomb business managers now know that they want to: • Compare regional performance to see which regions need additional interventions • Track high performing mobile users per region • See whether there is a link between members’ visits to the well and their health outcomes (# of sick days) over time • Track the poverty rate of their well site members by region, over time To review, Aquacomb has defined their objects, mapped out their workflows, and identified what information they’ll need. Specifically, they’ve identified the data that needs to be summarized at different levels, across different entities, and with various aspects of time. Goal
Data needed from what entity:
Summarize at what level?
Logging new records or updating records
Compare regional performance to see which regions need additional intervention
Income and other poverty measures of well site members
Regional
Logging new records since we want to track change over time
Track high performing mobile users per region
Number of site visits of mobile users
Regional
Updating records
See whether there is a link between members’ visits to the well and their health outcomes (# of sick days)
# of sick days, # of well visits of well site members
Well site
Logging new records since we want to track change over time
Track the poverty profile of well site members
Income and other poverty measures of well site members
Region
Logging new records since we want to track change over time
TaroWorks Implementation Guide
26
Phase 1 Summary Congratulations! You have reached the end of Phase 1: Define Business Objectives. By now you should have:
System Requirements met
Described your business processes that make up your operations.
Confirmed which key metrics you want reports for and how they should be presented.
Established some key metrics to measure the impact of implementing TaroWorks.
Identified who in your organization will be responsible for which part of the implementation and gaps in staffing, if any.
In the next phase you will build the optimal data model, taking into account of your processes and business requirements.
TaroWorks Implementation Guide
27
2. Configure Data Model
Phase 2: Configure Data Model This section will help you understand Salesforce databases and build your data model:
Using your Salesforce.com instance, you can build powerful databases and leverage features such as click and drag reporting without the need to do any traditional database programming
We will present useful guidelines on how to build a data model by taking your team’s objectives and processes outlined in the previous phase into account.
Phase 2 Checklist By the time you have completed this phase you will:
Be familiarized with Salesforce terminology such as objects, fields and relationships
Build your own custom database with objects and fields in Salesforce.com for your processes
Understand best practices when designing your data model and how TaroWorks leverage your data
TaroWorks Implementation Guide
29
Phase 2 Overview Salesforce Database concepts Why Relationships are Useful Relationships What is a data model? Why is this important? Building your data model • Define your Objects • Relate your Objects
TaroWorks Implementation Guide
30
Introduction
A database is an organized collection of information. Common examples include a phone book, a list of loan recipients, or in the case of Aquacomb, information about the wells they have built, the members using each well and data from the monthly visits.
A data model (also known as data structure or object schema) is simply how your data is organized, and it should reflect the relationships between them (eg. Each well member belongs to one well). The proper design of data model is important because how you store your information limits the reports that you can generate from it.
The Salesforce platform (also referred to as Force.com platform) is essentially a powerful relational database that allows you to manipulate your data without deep technical expertise. (We’ll set you up with the Basics in the next few pages!)
TaroWorks Implementation Guide
31
Salesforce Database Concepts Objects Salesforce uses terms that are specific to Salesforce, so let’s introduce you to these terms and concepts. For more detail and explanation of these terms, follow the Salesforce support links.
OBJECTS Salesforce page Typically, you use a database to collect information about people, things, or concepts that are important to you and whatever project you're working on. The collection of things (eg. Well Sites), persons (Well Site Members), or concepts (Member Visit Log) that you want to store information about is referred to as an object in Salesforce.com terminology. Note: In standard database jargon this is called an entity. If you have experience with other databases such as MS Access you might know this also as a table. Salesforce provides some Standard Objects like Contacts, but you will likely need to create Custom Objects that contain data for the entities that are specific to your organization.
Aquacomb Example Well Site Object Well Site ID
Region
Soil Type
Depth (m)
Status
Amber City East-1
Amber City East
Clay
18
Operational
Brasstown-2
Brasstown
Gravel
10
Under Construction
Carrotville-3
Carrotville
Clay
20
Operational
Carrotville-4
Carrotville
Rock
0
Rejected
TaroWorks Implementation Guide
32
Salesforce Database Concepts Records and Fields RECORDS In Salesforce terminology, a record is one specific instance of an object. See below how each row in the table contains information on a single well site that has been assessed.
FIELDS Salesforce page
Fields are attributes or characteristics that describe your object – essentially any information that you want to know. As a structured database, Salesforce.com provide many field types such as text, picklist, number, date that simplify how you can sort, filter, and report on.
There are also distinctions between standard and custom fields. Standard fields are those that are created by Salesforce. Most of them are found in standard objects.
Aquacomb Example Each column heading is a Field Ex: Status
Well Site Object Well Site ID
Region
Soil Type
Depth (m)
Status
Amber City East-1
Amber City East
Clay
18
Operational
Brasstown-2 Brasstown Gravel
10
Carrotville-3 Carrotville Clay
20
Under Construction Operational
Carrotville-4 Carrotville Rock
0
Rejected
TaroWorks Implementation Guide
Each row is a Record
33
Salesforce Database Concepts Data Value and Relationship DATA VALUE
Data value is a single piece of data you enter for a field of one single record.
RELATIONSHIP
Objects in the real world often time have logical relationships – In the Aquacomb example, all well sites belongs to a region and every member is associated to a well site. Salesforce.com allows you to define these relationships which are very useful in organizing and analyzing your data. We will discuss the two types of relationships and when to use them later.
Aquacomb Example
Each cell is a Data Value
Well Site ID
Region
Soil Type
Depth (m)
Status
Amber City East-1
Amber City East
Clay
18
Operational
Brasstown-2
Brasstown
Gravel
10
Under Construction
Carrotville-3
Carrotville
Clay
20
Operational
Carrotville-4
Carrotville
Rock
0
Rejected
Well Site Object
TaroWorks Implementation Guide
34
Why Relationships Are Useful Looking at Aquacomb table, you might see the similarities with spreadsheets like MS Excel and ask what the difference is. Well Site ID
Region
Soil Type
Depth (m)
Status
Amber City East-1 Amber City East
Clay
18
Operational
Brasstown-2 Carrotville-3 Carrotville-4
Gravel Clay Rock
10 20 0
Under Construction Operational Rejected
Brasstown Carrotville Carrotville
How would you add information about Well Site Members to the table above? You could add additional fields for well site members, starting with Well Site Member 1 – add Well Site Member 1 Name, Well Site Member 1 Gender, Well Site Member 1 Date of Birth… So for each member you need to add many more fields! This is very cumbersome to do even the simplest of analysis! (Imagine trying to figure out the number of male and female members in total.) Well Site ID
Region
Soil Type
Depth (m)
Status
Amber City East-1
Amber City East
Clay
18
Operational
Brasstown-2
Brasstown
Gravel
10
Carrotville-3
Carrotville
Clay
20
Under Construction Operational
Carrotville-4
Carrotville
Rock
0
Rejected
TaroWorks Implementation Guide
Member Member Member 2 (and 1 Name 1 Gender Name so on…) Mojo Male Him Male Jojo
Blossom Female Utonium
Bubbles Utonium
Female
35
Why Relationships Are Useful You can try adding more rows, one for each well site member – this seems to be more manageable, but now you see because of these additional rows it is harder to count the number of unique wells or tally well sites by their soil types. Furthermore if you need to change the status of a particular well site, you will have find and edit those cells many times.
Well Site ID
Region
Amber City East-1 Amber City East-1 Brasstown-2
Soil Type Amber City East Clay
Depth Status (m) 18 Operational
Member Name Mojo Jojo
Member Gender Male
Amber City East Clay
18
Him
Male
Blossom Utonium Bubbles Utonium
Female
Brasstown
Operational
Carrotville-3
Carrotville
Grave 10 l Clay 20
Under Construction Operational
Carrotville-3
Carrotville
Clay
20
Operational
Carrotville-4
Carrotville
Rock
0
Rejected
Female
Using the above approaches, data is repeated unnecessarily or organized inefficiently. In addition, there is really no way to capture additional information about members without having the simple table will quickly becoming extremely complex and unmanageable.
TaroWorks Implementation Guide
36
Why Relationships Are Useful As we mentioned, you want to create separate Salesforce objects (database tables) for each person, thing, or concept you want to track. A better way to model our scenario here would be to create one object for Well Site, one object for Well Site Members. Here are the two objects separated: Well Site ID
Region
Soil Type
Depth (m)
Status
Amber City East-1 Amber City East
Clay
18
Operational
Brasstown-2 Carrotville-3 Carrotville-4
Gravel Clay Rock
10 20 0
Under Construction Operational Rejected
Brasstown Carrotville Carrotville
Well Member Name
Gender
Well Site
Date of Birth
Mojo Jojo
Male
Amber City East-1
9/6/1996
Him
Male
Amber City East-1
12/3/1966
Blossom Utonium Bubbles Utonium Buttercup Utonium
Female Female Female
Carrotville-3 Carrotville-3 Carrotville-3
1/13/2000 1/13/2000 1/13/2000
Once we have our data separated into discrete objects, we can easily relate objects to each other. Here we have added the Well Site field (highlighted in yellow) in the Well Member object which tells us which site each member belongs to. This is what a relational database is all about! A relationship is an association between two or more tables. Now we can add as many members as we need or change data value easily because data is not repeated unnecessarily.
TaroWorks Implementation Guide
37
Recap: Database vs. Excel Original Excel File
Many unwieldy rows and columns Mobile User Name
Date
Well Location
Well Site Member 1 Name
Member 1 # Sick Days
Member 1 # Well Visits
Well Site Member 2 Name
Member 2 # Sick Days
Member 2 # Well Visits
Paul
3/1/12
Amber City East
Robert
2
10
Bernice
0
11
Mary
1/7/12
Brasstown
Jon
6
13
Jeffrey
2
15
Paul
4/1/12
Carrotville
Martha
3
9
Carol
2
7
New Data Model – easy to understand tables that relate to each other Well Site Object Well Site ID
Region
Soil Type
Amber City East-1 Amber City East
Clay
Brasstown-2 Carrotville-3 Carrotville-4
Gravel Clay Rock
Brasstown Carrotville Carrotville
Well Site Member Object Well Member Name Mojo Jojo
Gender
Well Site
Date of Birth
Male
Amber City East-1
12/3/1966
Him Blossom Utonium Bubbles Utonium
Male Female Female
Amber City East-1 Carrotville-3 Carrotville-3
1/13/2000 1/13/2000 1/13/2000
TaroWorks Implementation Guide
38
Relationships Parent vs. Child PARENT VS. CHILD
In the Aquacomb example, each Well Site record could have zero, one or multiple Well Site Member records related to it. We would call the Well Site the parent object, and the Well Site Member the child object. This concept is useful in reporting and also for identifying records when your mobile user is starting a job.
There are 2 specific types of relationships that you can use to relate your Objects in Salesforce.
Master-Detail
Lookup
TaroWorks Implementation Guide
39
Relationships Master-Detail MASTER-DETAIL A hierarchy relationship between two objects, where one object (the child or “Detail”) must have a Parent or “Master”. An example is in a school, there are multiple teachers. Schools would be the master object, the teachers would be the details. You wouldn’t have Teachers without a School.
In the Aquacomb example, well site members must belong to a Well Site. Therefore, Well Sites must be the Master or the Parent and Well Site Members must be the Detail or the Child. We can also summarize information on well site members up to get information on well sites
Well Site Object Region
Soil Type
Well Site ID
Amber City East
Clay
Amber City East1
Brasstown
Gravel
Brasstown-2
Carrotville
Clay
Carrotville-3
Carrotville
Rock
Carrotville-4
Well Site
Amber City East-1 Amber City East-1 Brasstown-2 Brasstown-2 Carrotville-3 Carrotville-3
TaroWorks Implementation Guide
Well Site Member Well Object Gender Date of Member Name Mojo Jojo Him JoJo Butter Blossom Utonium Bubbles Utonium
Birth Male
12/3/1966
Male
1/13/2000
Male Female Female
12/1/1990 12/2/1990 1/13/2000
Female
1/13/2000
40
Relationships Master-Detail MASTER-DETAIL
Each child record must have a parent record at all times.
If the parent record is deleted, all child records are also deleted.
You can create roll-up summary fields on the parent record that calculate useful things such as the maximum, minimum or the sum of a particular number field in selected child records. This the common reason for choosing this relationship type.
Each object can have at most two master records. (This is used when making junction objects for Many-to-Many relationships.)
Owner and security settings of the child record follow that of the parent record.
Aquacomb Example For Aquacomb, most relationships are master-detail. Well Site is the master of Well Site Member and Well Site Member is the master of the Member Visit Log object. (You can say that Well Site object is the grandparent of the Member Visit Log object). What about Region? Is that a field? Or should that be an object in its own right? Normally, a field would be enough, but the answer is here is that it should be its own object and the master of Well Site – this has to do with TaroWorks’ drill-down hierarchy feature and how records are assigned to mobile users which we will discuss later but for now simply accept that Region should be an object as well.
TaroWorks Implementation Guide
41
Relationships Lookup LOOKUP Lookup is the other type of relationship. It has the following properties:
It is possible for a child record to have no parent record. This is appropriate in some situations – a loan might not have a guarantor, a child might not have a god-mother.
From the Aquacomb example, the Well Site object is linked with the Officer object. Even though there is a one to many relationship (as in the case of Officer 1, responsible for 2 Well Sites), it is not a Master-Detail because Officers can exist without Well Sites and vice versa.
Well Site Object Officer Object
Region
Soil Type
Well Site ID
Mobile User ID
Mobile User Name
Amber City East
Clay
Amber City East1
Officer 1
Paul
Brasstown
Gravel
Brasstown-2
Officer 2
Mary
Carrotville
Clay
Carrotville-3
Carrotville
Rock
Carrotville-4
Officer 3
Joe
It’s also possible that objects are not directly related to each other. In the case of Aquacomb, the Officer object and Well Site Members object are not linked to each other directly, instead they are connected via the Well Site object. TaroWorks Implementation Guide
42
Relationships Links to important Salesforce Documentation for Relationships
•Lookup or Master-Detail Relationship? Video •Salesforce Platform Fundamentals •Object Relationships Parent or Child?
Given you have two objects, Farms and Farmers, which one is the parent? The answer is “depends”. Consider the following: • • •
Perhaps well-to-do farmers own multiple farms. In this case farmer is the parent object. Or perhaps one communal farm requires multiple farmers, in this case farm is the parent object. It is also possible that farmers tend to multiple farms as a many-tomany relationship.
TaroWorks Implementation Guide
43
Building your own data model in Salesforce What is a data model? A data model is a description of the objects represented in Salesforce together with their properties and relationships. The data model you create should reflect the collection of objects and fields that encapsulate your own organization’s activities and processes. To set up the data model for your organization, think back to the reports that you’ve outlined in the previous section. This is where your decisions about the types of information you’re collecting and the historical detail are important. - If you’re collecting information about certain things that will be updated (i.e. you only need the most up-to-date information), then you’ll need to create an Object that only holds that up-to-date information - Alternatively, if you’re reporting on results over time, you may need to create Objects that will log each visit as a separate record.
Why a properly built data model is important? The design of the data model is important because all survey responses must are stored in these objects for reporting. If the data object is not built correctly, such as lacking relationships or if you are missing data, your reports will be inaccurate, or not run. This is the reason why you examined your organization’s various objectives and the workflows, and the type of data you need, in the previous section. Now that you are familiar with the idea of data model, let’s get more into the details For more information: • Introduction to Data Models Video (focused on Nonprofit Starter Pack) • Salesforce Custom Objects Video TaroWorks Implementation Guide
44
Putting it together From outcomes and processes, It is time to put these together into a data model.
Sketch out the objects and fields you will need
What are the different “things” that you will need to describe and analyze? Starting with a whiteboard (or pen and paper ) record the objects, the information that you want to collect and the data type (is it date vs. date and time, number or percentage?). Again, objects can be a thing, a person, or even something intangible such as a sale transaction or an inspection visit.
In Aquacomb’s case, they will need at least Well Sites, Well Site Members and Member Visit Log.
Another key question to consider is whether it is enough to have the latest information (eg. current email address) or if you need individual records to capture historical “snapshots” to track changes over time.
Consider relationship between objects
Some relationships are an obvious hierarchy
Other relationships come about because they are useful. Aquacomb will definitely wish to have Well Member Visit log lookup to the mobile user that did the visit, this way they can run reports on the visits done by each mobile user and can perform analysis by mobile user’s characteristics on the outcome (Eg. Looking for patterns by demographic or experience). This is a good way to get more value out of Salesforce, though avoid going overboard with objects and relationships you won’t leverage for reporting.
TaroWorks Implementation Guide
45
To Do: Define your Objects The Salesforce Objects are the structures into which your data will be saved. You’ll need to determine both the Objects and also the Fields that each Object will contain.
Type of information List the entities that you’ll be collecting information about. Determine if you need up-to-date information or historical information. If you need historical information, you want a separate Object to track each time you collect that information. (i.e. Member Visit Log)
List out the information that you’ll be collecting for each of the entities. These will be the Fields in your Objects. (i.e. Number of Sick Days)
Example Aquacomb builds wells and wants to track members who go to the wells, and they want to log each visit the Mobile Users make to each Well Site Member. Object
Fields
Well Site -Well Site ID -Region -Soil Type -Depth -Status
Need only up-todate information TaroWorks Implementation Guide
Well Site Member -Name of member -Well Site -Birth Date -Gender
Need only up-todate information
Member Visit Log -Date of visit -Well Site -Number of Sick Days -Number of Well Visits
Need historic information 46
To Do: Define your Objects Examples (continued) A social enterprise wants to log sales of their products against customers
Object Fields
Customers -Name -Birth date -Village name
TaroWorks Implementation Guide
Sales Transactions -Date of sale -Product purchased -Quantity -Amount collected
Products -Product ID -Product name -Product description
47
To Do: Define your Fields Now it’s time to determine what information you want to include in your data model. Look back at your objectives and workflow. What data do you have already? What is missing? You can use TaroWorks to gather that missing information Object
TaroWorks Surveys •--------•--------•--------•---------
Mobile User ID
Mobile User Name
Officer 1
Paul
Officer 2
Mary
Fields Records (Rows)
Officer Object
Each response you collect in the TaroWorks mobile survey will need to be stored in Salesforce in a field
TaroWorks Implementation Guide
48
To Do: Relate your Objects What kind of relationship should I use? Well Site -Well Site ID -Region -Soil Type -Depth -Status
Master-Detail Relationship (hierarchy: Well Site members belong to a Well Site)
Well Site Member -Name of member -Well Site -Birthdate -Gender -Officer
Member Visit Log
Master-Detail Relationship (hierarchy: Each visit is logged against a Well Site Member)
TaroWorks Implementation Guide
-Date of visit -Member -Number of Sick Days -Number of Well Visits
49
Voila – your data model! Your data model should have all of the objects you need, for the various levels of information you’ll plan to report on, along with the right relationships. Here is Aquacomb’s final data model, as it relates to their well member check-in process. From here they are able to summarize the health status of their Well Site Members, per Well Site. This is useful for the following goal: Understanding the link between number of visits to the well and their health outcomes. More can be added to this data model in order answer their other goals. Well Site -Well Site ID -Region -Soil Type -Depth -Status
Master-Detail Relationship (hierarchy: Well Site members belong to a Well Site)
Well Site Member -Name of member -Well Site -Birthdate -Gender -Officer
Member Visit Log
Master-Detail Relationship (hierarchy: Each visit is logged against a Well Site Member) TaroWorks Implementation Guide
-Date of visit -Member -Number of Sick Days -Number of Well Visits 50
Build your Data Model in Salesforce BUILD YOUR DATA MODEL
You’ve sketched out your data model – put it into Salesforce by navigating to Setup -> App Setup –> Create -> Objects
Choose New Custom Object to create your new Object and Custom Fields.
Give your TaroWorks users access to your new objects and fields
Links to Videos • •
Simple - Create Custom Object and Fields Extended Hands-On Training – Salesforce Custom Objects
TaroWorks Implementation Guide
51
Phase 2 Summary Congratulations! You have reached the end of Phase 2: Configure Data Model.
By now you should have:
Understood database and Salesforce concepts
Drawn out the objects that you need for your business processes and relationships between them
Set up your data model in Salesforce
At this point in the implementation, the model doesn’t have to be final. You will be testing your data model in the next phase with Jobs and Surveys in TaroWorks.
TaroWorks Implementation Guide
52
3. Configure Jobs and Surveys
Phase 3: Configure Jobs and Surveys This section lays out how Salesforce helps you organize your data and how TaroWorks packages your processes neatly into Jobs, streamlining the work of your mobile users and mediating the data flow to and from the field.
Phase 3 Checklist:
By the time you have completed this phase you will:
Understand the concept of a Job in TaroWorks and how it interacts with the database and streamlines the work of your mobile users.
Create TaroWorks Jobs ready to be deployed to the field.
TaroWorks Implementation Guide
54
Phase 3: Configure Jobs and Surveys TaroWorks allows you to exchange data between a mobile device and a cloud database using Jobs and Surveys. More specifically, you use hierarchydrill downs in your Jobs to pull data out of Salesforce, and field-mapping in your surveys to sync data in to Salesforce.
Hierarchy DrillDowns
ANDROID
Field-Mapping
TaroWorks Implementation Guide
55
Definitions
Job - is a process to be completed by a mobile user.
Task - a Task is a step in the process to be completed by a mobile user, and there are three types: • • •
View Resource Task – Displays a file from the TaroWorks Resource Library View Data Task – Displays a record Collect Data - displays a form in which the user can enter responses to questions, and those responses can be captured and sent to Salesforce
Survey - a series of questions to be answered within a single Collect Data Task.
Resource - files that can be displayed in View Resource Task.
Well Site Member Check-in
Job
Tasks
Get Site Info
Surveys/Resources
TaroWorks Implementation Guide
Show Video
Check-In
Program Overview Video
Well Site Check in Survey
56
Defining Jobs for your Organization Now that you know what Jobs and Tasks are, you may be asking yourself which of your organization’s processes would be confined to a single Job. Here are some considerations:
Timing – the single biggest consideration when defining what tasks or tasks should be contained within a single Jobs is timing. Because syncing occurs at the Job level, ideally you would want a mobile user to be able to complete the task(s) within a Job within a single field visit so that you have the associated data in Salesforce as soon as possible.
Audience - since you can deploy Jobs to certain groups of mobile users you may want to create a Job geared toward a particular set of mobile users.
Using Existing Data – if you want to pull existing data out of Salesforce for use within a Job, this is defined in the at the Job level. Therefore, if you have different processes that need to use existing data from different objects, you may want to consider using separate Jobs.
TaroWorks Implementation Guide
57
Aquacomb Jobs Previously we looked at some processes in our Aquacomb Example. Let’s choose the 3 below and think about how to translate this into TaroWorks. Since each of these are individual processes and are likely done in separate field visits, they would each be created as a unique Job in TaroWorks.
Aquacomb Example 1. Conduct Well Site Assessment- Assess a Well Site for construction 2. Register a Well Site Member - Register members using a particular well 3. Well Site Member Check-In – Record regular visits to registered well site members
TaroWorks Implementation Guide
58
Job 1:Conduct Well Site Assessment Aquacomb Example
Let’s start with the first Job. You want your Mobile Users to visit and collect information about a site that you’re evaluating for the construction of a well. As a result of this process you would like to create a well site record in the system. Since we will be gathering information about the well site, we will use a Collect Data Task.
TaroWorks Implementation Guide
59
DELETE In order to collect information about the well site for this Task, we need to create a survey defining the questions that the mobile user is to ask. The detailed steps to creating a survey can be found on our Customer Support Site. Statuses:
Draft - the Survey is still a work in progress
Published – the Survey is complete and can be added to a Collect Data Task
Closed - the Survey is no longer in use, but can be Previewed or Cloned. You cannot close a Survey if it is being used by a Task in a Published Job.
Cloning:
Surveys can be cloned (copied) into new survey, but must be saved with a unique name
Steps: 1.
Question Builder
2.
Logic (Optional)
3.
Scoring (Optional)
4.
Field Mapping
TaroWorks Implementation Guide
60
Creating Surveys Every Collect Data Task requires a survey. On your survey you’ll want to create a question for each piece of information you want the mobile user to collect. The detailed steps to creating a survey can be found on our Customer Support Site.
Aquacomb Example In order to determine whether a well can be built at this location, we need the mobile user to collect data such as the Region the site is in, the soil type, number of households around the well, etc. When creating your survey, envision how your mobile users will be obtaining the responses to these questions, so you can phrase and order your questions accordingly.
TaroWorks Implementation Guide
61
DELETE In order to streamline the time it takes to complete a survey, you can implement logic to have certain questions skipped. For example, if we were gathering data about the well site member we are registering and there are a series of questions about the healthcare they received if they were sick, we would not want to waste time asking these questions if they’d answered that they weren’t sick this month in a previous question. The detailed steps to implementing question logic can be found on our Customer Support Site. Some Important things to note about Question Logic:
By default, all questions are set to ’Show Always’
Logic rules are driven by conditions that are always based on answers to preceding questions
Skipped questions return blank values to fields that are mapped to
TaroWorks Implementation Guide
62
DELETE Scoring (or weighting) allows you to evaluate responses to surveys in a mathematical way, by assigning a numerical value to individual multiple choice answers to certain questions. For example, an organization may want to create an index to gauge the level of gender equality and access to education from its respondents. By assigning relative values (0-100) to the answers of relevant questions for each index, TaroWorks can then sum the values for the selected responses for each interviewee for each index. This allows for comparative quantitative analysis on what would otherwise be qualitative survey responses. The detailed steps to implementing question logic can be found on our Customer Support Site.
TaroWorks Implementation Guide
63
DELETE Some Important things to note about Scoring:
Only the sums of scoring groups are stored, whereas the score values contributed by individual questions are not stored.
It is currently not possible to map the scores to a field. As a result the scores for each survey submission can only be seen / exported as .csv file from the responses though Survey Manager. (Exception: The raw Progress out of Poverty Index (PPI) can be mapped to text and number fields when using the special PPI templates.)
Sums of scoring groups cannot be displayed on the device as it is calculated in Salesforce.
For the same reason, logic cannot be triggered based on scoring. (Eg. It is not possible to show a question if the score total is over 100.)
Scores from questions in repeat sections are added together
The score of a response is note visible to the mobile user as they are completing the survey
TaroWorks Implementation Guide
64
Creating Surveys: Field Mapping As a part of Survey creation, you configure where the responses are stored, which is called Field Mapping. In order to store information in Salesforce for Dashboards, Reporting, and reference for future surveys, the responses in your surveys need to be mapped to the Fields on Objects in Salesforce that you created in Phase 2. The detailed steps to implementing field mapping be found on our Customer Support Site. There are a few ways you can map objects and fields to update information in Salesforce based on whether you want to do the following:
Create a new Record for an Object
• To create a new record for an object you need to add the object then minimally map all the required fields to create a record for that object to each of the corresponding survey questions Update an Existing Record for an Object
• To update an existing record for an Object, you’ll need to map and then populate the ID Field at the top of the page that the system should use to select the record for updating • When updating an existing records, if the id for the record is not found, the system will create a new record Use an Existing Record for an Object as a Reference
• If you’d like to use information on an existing record to create/update a record on a different object, you can add the object as a reference object by checking the corresponding box and map and then populate the ID field If you’d like to do any of these for objects which are related to each other within a single survey, you’ll also need to enter the relationship between those objects.
TaroWorks Implementation Guide
65
Creating Surveys: Field Mapping Creates a new Record for an Objects Well Site Member and Well Site Visit Use an existing record for the Well Site Object as a reference
Creates relationship between Well Site and Well Site Member records Create relationship between Well Site Member and Well Site Visit records Fields to populate or reference on each respective object’s record with the question responses
TaroWorks Implementation Guide
66
DELETE Some Important things to note about Field Mapping:
Once you have mapped an Object for use in a survey, the following actions will negatively affect the survey and could cause data to be lost: • •
Deleting the object Changing the object’s name
Once you have mapped a Field for use in a survey, the following actions will negatively affect the survey and could cause data to be lost: • • • •
Deleting the Field; Changing the Field Name; Changing the Field Type; and, Adding or Changing Validation Rules
For each data collection task done in a job run, a set of Submission Data are generated. These can be mapped to fields in the same way as you would map questions and can be useful in specific situations.
Often it is desirable to create/update multiple records of the same object within one job run using Repeating Questions.
Here are a few vital references for field mapping: • • • • •
Question-Field Mapping Compatibility Table Intermediate Field Mapping Guide Field Mapping - Modify Records with Upsert Field Mapping - Creating Related Records Field Mapping - Using Reference Objects
TaroWorks Implementation Guide
67
Survey for Job 1 Aquacomb Example
In our first Job, we want to have a survey that will create a Well Site record that belongs to an existing Region record. Since we are not updating the Region record, and only using it in order to tie it to the new well site we are creating, the Region Object will be a reference object. We will be able to tie the new well site record to the existing region record using the region’s name which will be collected in the first question.
TaroWorks Implementation Guide
68
Survey for Job 1 Once you’ve created the survey, you can add it to the Task. Once the survey is published you can also publish it to your Mobile Users, and it will appear on the next Sync.
TaroWorks Implementation Guide
69
Job 1 on Mobile Once the Job is published and the mobile user performs a sync, the following is what they will see on their device.
TaroWorks Implementation Guide
70
Job 1: Data in Salesforce after Sync Aquacomb Example When the mobile user performed a sync, Well Site Carrotville-53 was added to Region Carrotville.
TaroWorks Implementation Guide
71
Job 2: Register Well Site Member Aquacomb Example
Now let’s walk through a similar Job .You want your Mobile Users to register a Well Site Member to a Well Site. You want them to collect the details you need to be able to identify the individual for future visits. Rather than have the mobile user type in the name of the Well Site, we are going to use a drilldown hierarchy to allow them to select the appropriate well-site from a list.
TaroWorks Implementation Guide
72
Drill-down Hierarchies In order to pull information out of Salesforce for use in your Jobs, you must use a drill-down hierarchy. A drill-down hierarchy is a hierarchy of parentchild records that is displayed in order for your mobile user to drill-down to a particular record. The lists of records to choose from, will dynamically display the child records of the parent record selected in the prior list. Once the mobile user has drilled down through the hierarchy, they can either view information about the final record selected with a View Data task, or they can use information about any of the records they have selected throughout the hierarchy to pass into responses to a survey using the Collect Data task. Aquacomb Example For our example we need well-site information from Salesforce in order to assign as new Well Site Member to it. In order to reduce the number of Well Sites the mobile user has to choose from, the first level of the drill-down hierarchy will display a list of Regions (which is a parent object of Well Sites). Once a region is selected, the next list that will be displayed is that of all the well sites in the region selected. This enhances the user experience, and reduces the chances for human error by not having to manually type in a the name of the well site, as we did with the Region value in Job 1.
Region
Well Site TaroWorks Implementation Guide
73
Drill-down Hierarchies What are the Benefits? The benefits of a drill-down hierarchy are: Reducing data entry errors by being able to select the records you want to read, update or associate other records with from a list Interacting with dynamic data as new mobile record assignments with automatically go to the device with every sync Making finding a record easier by letting user the drill-down through levels in order to narrow the search Aquacomb Example Revisiting our data model, if we had the information below in Salesforce, we could create a drill-down hierarchy where the mobile user would first select a Well Site, then a Well Site Member, and finally a Member Visit Log, and any of the fields from those records could be viewed or used as a response to a question in a Survey. Well Site -Well Site ID -Region -Soil Type -Depth -Status
Well Site Member -Name of member -Well Site -Birthdate -Gender -Officer
TaroWorks Implementation Guide
Member Visit Log -Date of visit -Member -Number of Sick Days -Number of Well Visits 74
Drill-down Hierarchies Starting with the highest level object that you’d like to be selecting from, you want to enter the object and the field that will be displayed to represent each record in the list that the mobile user will select from. You can also select fields for that record that are displayed in a subsequent detail view. If you want a field to be passed into the survey, it must be in the Selected Fields List for the detail view. Region
TaroWorks Implementation Guide
75
Hierarchy Drill-Downs The process is the same for the second level object. You can set up a single branch of parents and children per job. In other words, the only Objects that will be presented in the Object menu to select will be Children of the object in the next higher level. Well Site
TaroWorks Implementation Guide
76
Survey for Job 2 Aquacomb Example In our second Job, we want to create a Well Site Member record that belongs to an existing Well Site record. Since we are not updating the Well Site record, and only using it in order to tie it to the new well site we are creating, the Well Site Object will be a reference object. We will be able to tie the new Well Site Member record to the existing Well Site record using the Well Site’s name. However, for this Job, we are going to pass the Well Site name into the response for Question 1, so the field office does not have to type it in. The configuration to pass data in or prepopulate a response to a survey question is done on the Task level.
TaroWorks Implementation Guide
77
Job 2 – Passing Values into your Survey Once you’ve created the survey, you can add it to the Task.
Aquacomb Example In order to pass in the name of the Well Site we need to map the object field we are pulling in from Salesforce, to the question/survey field we want the data to be passed into.
TaroWorks Implementation Guide
78
Job 2 Once the survey is published, you can also publish the Job to your mobile users. The Job will appear on the next Sync. However, the drill-down hierarchy will not display unless you have assigned the mobile user records to choose from.
TaroWorks Implementation Guide
79
Assigning Mobile Records In order for a Mobile User to view an existing record, they must be given access via Mobile Record Assignments. When you give access to a parent Record, you are also giving access to all of it’s children. The detailed steps to assign Mobile Records can be found on our Customer Support Site. Aquacomb Example For Example, if I give a add the Carrotville Region Record to a Mobile User’s account, that Mobile User will have access to all of the Well Site records Forthat example, if I assign the as Carrotville Region to a Mobile that person are in that Region, well as the WellRecord Site Members thatUser, are children willrecords have access all ofSite, the etc. Well Site records that are in that Region, as well as the of thattoWell Well Site Members that are child records of that Well Site, etc.
The level at which you manage mobile record assignment is a trade off between keeping maintenance low and minimizing the number of records that will be sync’d to your mobile users’ devices. Ideally, you would manage your mobile record assignment at a high enough level such that when new pertinent data is created, it would automatically be added to the mobile user’s device on the next sync, as it would be a child of a record already assigned to the mobile user. However, the more data that you send to the device, the longer the sync, so minimizing the assignments to only the data that is relevant to that mobile user is also ideal. Region
Well Site
Well Site Member
Well Site Member Log
TaroWorks Implementation Guide
80
Job 2 on Mobile Once the Job is published and the mobile user performs a sync, the following is what they will see on their device.
TaroWorks Implementation Guide
81
Job 2 on Mobile
TaroWorks Implementation Guide
82
Data in Salesforce after Sync Aquacomb Example
When the mobile user performed a sync, Well Site Member Erin Yamaoka was added to Well Site Amber City East-18
TaroWorks Implementation Guide
83
Job 3: Well Site Member Check-in Aquacomb Example For the final Job, you want your mobile users to return to visit the well site members they have registered in order to conduct a check-in. We want to gather information about the member’s health and how often they are using the well. Since we want to associate this check-in information with a member record that already exists in the system, we can use the drill-down hierarchy to pull the ID for that record from Salesforce.
TaroWorks Implementation Guide
84
Survey for Job 3 Aquacomb Example In the survey for our third Job, we want to create a new Well Site Visit record that is associated with a Well-Site Member, therefore we will not populate the ID field or make it a reference object. For the Well Site Member record, we want to update this record with the photo from the most recent check-in, so we will populate the ID field which signifies which record to update. However, since we are changing something about the record, we will not make this a reference object. Finally the Well Site will be a reference to the Well Site Member.
TaroWorks Implementation Guide
85
Job 3 – Passing in Values Aquacomb Example Once you’ve created the Survey, you can add it to the Task. In order to pass in the name of the Well Site and the name of the Well Site Member from the drill-down hierarchy selection, we need to map the object field we are pulling in from Salesforce to the questions/survey field we want the data to be the response to.
TaroWorks Implementation Guide
86
Job 3 Once the Survey is published you can also publish the Job to your mobile users. It will become available on the next sync.
TaroWorks Implementation Guide
87
Job 3 on Mobile Once the Job is published and the mobile user performs a sync, the following is what they will see on their device.
TaroWorks Implementation Guide
88
Job 3 on Mobile
TaroWorks Implementation Guide
89
Data in Salesforce after Sync Aquacomb Example
When the mobile user performed a sync, Well Site Member Erin Yamaoka was updated with a new photo and the Well Site Member Visit was created.
TaroWorks Implementation Guide
90
Data Flow Remember when building you’re building Jobs that if you want to get data out of Salesforce to use in your Job, you need to employ drill-down hierarchy to retrieve the data. To map that data to survey questions, you then need to define those mappings on your Task. Finally to control how data is written back to Salesforce, you would use field mapping on your Survey.
Hierarchy DrillDowns
ANDROID
Field-Mapping
TaroWorks Implementation Guide
91
Phase 3 Summary Congratulations! You have reached the end of Phase 3: Configuring Jobs and Surveys By now you should :
Understand how data flows between TaroWorks and Salesforce
Understand the concept of a Job in TaroWorks and how it interacts with the database and streamlines the work of your mobile users.
Be able to create TaroWorks Jobs ready to be deployed to the field.
For more information, please visit the following on our Customer Support Site:
Jobs and Tasks
Survey Questions
Intermediate Field Mapping
TaroWorks Implementation Guide
92
4. Deploy
Phase 4: Deploy This section lays out how to deploy TaroWorks for your organization. This section will discuss the best practices involved in procuring a large amount of devices, the actual training for mobile users, tips for handling the initial roll-out until mobile users use TaroWorks as an extension of themselves and the entire business process runs smoothly.
Phase 4 Checklist:
Procure Devices
Field Test your instance
Train your Team
TaroWorks Implementation Guide
94
Deploy: Procuring Devices When possible it’s always best to try a device out in the field before procuring a large lot of them, to ensure you’re getting the best device for your operations. This may uncover strengths or weaknesses that may not be obvious when using the device in the back office, such as screen glare, GPS functionality, durability, battery life, etc. If you’re making an international purchase be sure to leave yourself plenty of time for the unexpected. In our experience many countries our customers work in are sensitive about importing electronics, especially in bulk. So even if you know the process, allot yourself plenty of time to receive the devices prior to your implementation.
Some devices our customers use (2014)
System Requirements for TaroWorks
TaroWorks Implementation Guide
95
Deploy: Field Testing Field testing your TaroWorks Jobs and Surveys can have a great impact on the overall success and adoption of your rollout. While budget and timelines don’t always allow for a pilot, it is STRONGLY encouraged. Obtaining feedback from the field will allow you to make changes to TaroWorks and/or your processes before trying to scale the implementation.
Field Testing Best Practices:
Communicate early and often that the initial rollout is a pilot, and set the expectation is that improvements will be made
Test with a small subset of your mobile users under observation
Use feedback from the test to optimize jobs and surveys
If possible, employ a phased approach, starting with Jobs that most improve the work lives of your operations teams
Share the feedback you receive from the field test with everyone involved
TaroWorks Implementation Guide
96
Deploy: Training Deployment Best Practices:
Use relevant test data as much as possible
For hands on training class sizes of a maximum 6-8 students per teacher is ideal
Training Topics:
There are 3 types of audiences that may require training for TaroWorks: Mobile Users (TaroWorks Partner Users), Job and Survey Admins (TaroWorks Users) and System Administrators (System Administrator).
TaroWorks also offers training support should you need it: • •
•
•
Salesforce-for-TaroWorks Training (Onsite and Virtual available) • 8 hours of training, including customized reference materials Field Staff Training (Onsite and Virtual available) • 8 hours of training, customized to the users’ devices and data collection tasks. Focuses on installation, troubleshooting and resolving common issues. Includes reference materials. Training of Trainers (Onsite and Virtual available) • Gives you the tools to train your field staff. Focuses on setting up/maintaining devices, • conducting jobs, resolving common issues, and training tips. Includes reference materials. Ongoing Consulting • Up to five hours per month of consulting for new or changing processes as your organization evolves
TaroWorks Implementation Guide
97
5. Maintenance
Phase 5: Maintenance Once your operations using TaroWorks has reached a steady state, there are various items that requires your attention to keep the system working smoothly. Regularly checking on storage usage, installing the latest version and other such maintenance will ensure that you will continue to experience trouble-free operations.
Phase 5 Checklist: By the time you have completed this phase you will:
Monitor ongoing progress of your mobile users.
Be able to manage upgrade to TaroWorks.
Manage device usage by your field team.
TaroWorks Implementation Guide
99
Monitor Progress Monitoring mobile users’ progress
Use reports on custom object as records are created, grouped by the mobile user’s name. This is often the best way as it allows you to analyze by specific metrics such as total sales or % served by gender where the data simply “falls out”. The reports can be scheduled to run automatically and be emailed to the team.
If you need mobile users to hit a weekly or monthly target and they want to keep track of their progress on their Android devices, you should use TaroWorks’ performance management to encourage productivity.
It is also a good idea to regularly check with your mobile users and ask them for feedback, report problems and suggest improvements.
TaroWorks Implementation Guide
10 0
Manage Devices Managing field device usage
Encourage mobile users to charge their phones often and avoid running it down completely as depending on the battery technology used, completely discharging a phone can significantly reduce its charge capacity and life. It is possible to monitor battery drain by application in the Android settings menu.
The TaroWorks Android app require about 100MB of RAM for typical use case. This increase with the size of the survey being done and grows quickly if photos and signatures are used. If there are too many other apps open it may cause TaroWorks to close unexpectedly.
Mobile users should be discouraged from downloading too many apps or other files (often movies) that can destabilize TaroWorks.
You will need to either purchase data bundles or reimburse your staff for them when working in the field. The data usage can be monitored in the Android settings menu. Some network providers may offer advanced account features to help you manage costs better.
It is recommended that you establish SOPs to minimize the risk of theft or lost of the device. Using Google’s Android Device Manager, it is possible track the device, make it ring, lock it and if necessary wipe the device.
TaroWorks Implementation Guide
10 1
Manage Upgrades Managing TaroWorks upgrades
The TaroWorks team will continue to release new versions of the software to provide customers with new features, better usability, and higher stability. As a TaroWorks customer you will receive email notification of the upcoming changes with links to video and documentation for any new releases.
Read and understand the release notes and any accompanying documentations and videos before installing. This is important as it is not possible to roll back to an earlier version of the managed package in Salesforce.
Be aware of Auto-update. By default when a new Salesforce version of TaroWorks is installed, it will signal all devices to upgrade the Android app. Thus it is best to schedule it when your mobile users have a stable connection and their devices should have sufficient battery and storage space for the installation. Finally if the download will occur over a mobile connection, ensure sufficient data has been purchased.
If you have any questions or encounter any disruption to your operation and cannot resolve it through the TaroWorks Support Center articles, please contact
[email protected]
TaroWorks Implementation Guide
10 2
APPENDIX
Glossary of Terms
Dashboard – a visual representation of data in your reports
Data model – the structure in which your information is stored in Salesforce
Field mapping – the process of tell TaroWorks what Object and Field Survey individual survey question responses should be stored in.
Drill-down hierarchy – a defined hierarchy of parent child objects that allows a mobile user to drill down to a particular record..
The ID field for identifying and selecting a record in each level of the hierarchy is also defined. • Any additional fields for display associated with that record are also defined. Job - a series of related tasks for a mobile user to complete.
Mobile User - accesses the TaroWorks front end via a mobile device.
•
Interchangeable with “Mobile User” in the TaroWorks context Also can be referred to as a “Partner Community User” in TaroWorks 3.0 and beyond Object – a database table or entity. Think of an object like a worksheet in Excel where you would define many characteristics/columns all about the same entity. (Example: Farmers) • •
Record – an singular instance of an object. Following the Excel analogy, a row in an Excel Worksheet. (Example: Mary Smith)
Report – a query on existing data from a single object or many related objects displayed in a manner to efficiently answer important questions for your organization.
Survey - a definition of questions to be answered within a single Collect Data Task.
Task - a unit of work that can be of the following types:
• Display Data • Collect Data • View Resource TaroWorks Implementation Guide
10 4
Measuring Impact There are many ways that TaroWorks can deliver value to your organization. It is recommended that key stakeholders prioritize the pain they are trying to solve and establish some clear metrics to evaluate the benefits of implementing TaroWorks. Here are ways to explore and quantify common issues affecting your organization’s ability to scale effectively:
Issue with data accuracy and completeness: How often does this happen? How crucial was the data lost? Did errors lead to wasted resources, such as send out someone on a long trip needlessly or contribute to poor outcomes for clients? This can be measured in frequency of errors per form processed.
Issue with productivity: How many activities can a mobile user perform per day under the existing process? Is there time lost to paperwork, transcribing data and creating same reports manually on a routine basis?
Issue with speed: How long does it take for clean data to reach the right people? Does this put key milestones such as donor reporting at risk? Does this lead to customers leaving, frustrated by long turnaround times?
Issue with cost: Consider the entire process, how many person-hours does it take to process 100 clients? How would this translate when different staff’s salary are taken into account? This can be normalized to cost per unit work done.
Issue with reach: Are there population that you could not serve or opportunities missed because operations would have been too difficult or costly? With the capabilities afforded by TaroWorks, what new areas and businesses is now possible?
Issue with compliance: Do you need to audit work done in the field to ensure compliance with set standards? Would your organization be a risk to lose certification or funding if evidence cannot be produced on time?
Issue with staff satisfaction: Often they need to travel great distances and work long hours, and as the face of the organization on the frontline, bears the brunt of client dissatisfaction. Is incorrect, tardy information frustrating your mobile users? Are they spending energy on non-value adding paperwork? Do they suffer from disconnect of how their work contribute to the organization’s mission? Opinion survey before and after would help identify progress.
Our customer success manager would be more than happy to assist you in defining your10 TaroWorks Implementation Guide 5 success criteria and metrics.
Other Resources
Actions to avoid when using TaroWorks
Release Notes and FAQ’s
Creating and Managing Users
Security References
Maps
Reporting and Analysis
Troubleshooting
TaroWorks Implementation Guide
10 6
