Database Design Considerations

Introduction

In order to most effectively leverage Salesforce's reports and dashboards, the data that you collect with TaroWorks should be stored in Salesforce objects and fields. There are three things you should consider when designing your database schema, or the way that these objects will be organized:

• A. Timing - Does the data you're storing in a single object represent the most current information or capture many snapshots over time?
• B. Mobile Record Assignment - It is best practice to always start your drill-down hierarchies with the same objects from which you're assigning records.
• C. Future Expansion -  what new objects could come into play into the future, and how can I ensure a flexible architecture for this expansion?

A. Timing

While not necessarily TaroWorks specific, it is more clean for your reporting to considering timing when considering what fields will be created on what objects. A common use case with our clients, is the concept of having customers and checking in with those customers. When a mobile user is registering a customer into the system, they may collect information that over time they may want to overwrite and other information that they do not when making submissions with TaroWorks.

For example, let's say I don't care to keep records for historical information for the customer contact information. I don't care what the person's old phone number was or old address, I just want the latest contact information to be store in the system. However, I'll also be inquiring about the financial status of the customer. For financial information I do want to capture historical information so I can measure progress over time.

Because the nature of the timing for which you'd like to report on these two types of data is different, you would create two different objects: Customer and Financial Log. In your TaroWorks Jobs, you could then create field mapping such that any new customer contact information, would overwrite the stale information, and a new financial log record would be created with each submission, such that historical records are kept in tact.

B. Mobile Record Assignment

A powerful differentiator for the TaroWorks application is the two-way data flow between the Salesforce database and the mobile device. To determine which records get sent to each mobile user, the administrator assigns records to individuals using mobile record assignment. For each record that is assigned to the mobile user, the pertinent fields needed for that user's Jobs, and pertinent fields for all child records of that assigned record, will be synced to the user's device.

Due to the inheritance element of mobile record assignment, you may want to consider at what object level this will be managed such that you're designing a good user experience for both your admin and your mobile users. Deciding the level at which you manage mobile record assignment can be a trade off between reducing administrative tasks and minimizing the data that is synced to the user's device such that they are only receiving exactly what they need. This reduces sync times, and avoids the user having to view unnecessary data in their drill-down hierarchies.

For example, let's say a customer is planning to have Region, Client, and Client Log objects where Region is a parent object to Client and Client is a parent to Client Log. The main records that the mobile users will be working with is Client and Client Log as they register new people and then periodically check in with them.

We don't want to manage mobile record assignment on a Client level, because every time a new client in created, an administrator would have to manually assign that new client record to the pertinent mobile user or users. However, each field officer only needs about 5% of the total records you might find in a single region, so we don't want to assign a region to a mobile user and have 95% of the clients that appear in a drill-down hierarchy be irrelevant to them.

Therefore, this customer may want to create an object District to set in between the Region and Client objects and manage mobile record assignment on that level. Since it's not common that a mobile user will expand into a new district, this will require little administrative intervention. And you can also assign more than one district if a user works in more than one area. Finally,  a new Client record is generated, this record will automatically be synced back out to the mobile user(s) since it is a child record of an assigned district.

Best Practices in Mobile Record Assignment:

1. Start your Jobs drill-down hierarchies with the same objects from which you're assigning records.
2. Do not assign related records to a single mobile user.
3. Conduct mobile record assignment at least one level above where new record generation commonly occurs so that TaroWorks administrator doesn't need to assign new mobile records assignment for mobile users that need access to newly created data.
4. Consider the maximum volumes of data you can push to the device.
5.  Limit mobile record assignment to only the data needed by the mobile users for their duties to shorten sync time and create a more efficient user experience.

C. Future Expansion

When discussing your customer's data requirements, be sure to get an understanding of not only what they need to do on mobile today, but how plan to grow. Specifically you want to look for anticipated changes that could impact part A. and B. in this article.

For example, maybe mobile record assignment makes sense on a District Level for now, but if growth within two years anticipates a single field officer focusing in a single sub-district, you may want to go ahead and create that additional object such that you can adjust mobile record assignment to be on a sub-district level in the future.