STORY BANK TOOLKIT

Building an Infrastructure

How to Design a Database One of the first questions organizations ask themselves when they decide to start a story bank is, “How will we store our stories?” There’s good news and bad news: The good news is that there are countless options on the market today, and with a bit of effort, you should be able to find something that meets most of your organization’s goals. The bad news is that there’s no magical, one-size-fits-all solution. What works for one organization will be another’s nightmare. The database your organization selects should depend on your needs, available resources, and the types of information you intend to store. No two organizations will have the exact same requirements. Some organizations will find that an Excel spreadsheet works well, while others will need something more sophisticated. You may find that your organization already has a system in place that can manage contacts, and you’ll need to make only a few modifications. NOTE: Even if you settle on a system tomorrow, it is smart to evaluate your database regularly to make sure you’re getting what you need from it. You may find that you use a number of systems throughout your story bank’s lifetime. You may move from a paper filing system to a spreadsheet to custom-built software to several different databases. This kind of evaluation and growth will be necessary as your story bank evolves and as new technologies emerge. Choosing a database can be overwhelming for anyone. It is possible for you to find consultants who specialize in this work, though it’s an expense that not every organization can afford. Think through how your database will improve your story bank work and educate yourself about the kinds of options available.

Three elements will help guide your decision-making when choosing a database to use for your story bank: 1. The function it will serve in your organization 2. How you want to organize data and which technical features are essential 3. Your budget If you have questions about terms, see “Simple Database Vocabulary” on page 5.

1. Determine the Function of Your Database and How It Will Serve Your Organization Before you explore your options, you should determine your organization’s basic infrastructure needs and how you want your database to serve you in key areas of your work. Then, determine which features are essential, nice to have, and not necessary. Determine what type of basic information your database will house One of the most basic questions you should ask about the database is, “What are we hoping to store?” Some organizations may want to upload only page-long, written

Building an Infrastructure

stories, contact information, and names. Others may want to house multimedia content and organize it through relational data fields (also called one-to-many or parentchild). Be clear about the core purpose of your database before you begin any investigation. Determine how your organization will use your story bank database It is equally important to figure out how your organization will use a database for more than just storing notes about consumers in your growing story bank. Spend some time envisioning how the database will fit into your organization’s day-to-day work and how it will help you complete other tasks. The database might benefit several different areas of your work, like performing complex searches, tracking requests and story appearances, recording how frequently you attempt to contact story bank participants, generating and creating reports, and managing projects. Determine who needs access to the story bank and where The other core concern is understanding and being intentional about who has access to your story bank. If your story bank is a one-person operation, then you could decide to use a program that lives on one computer and doesn’t require remote access. But if you are an organization that has multiple people using the story bank on a daily basis, whether in one office or in several, your best bet might be something that is cloud-based. Think through what makes sense for your organization in terms of granting access to your story bank. Pay special attention to if and how you grant access to any organizations you partner with in your story bank efforts. Will partner organizations need access? And what kinds of information will these partner groups need access to? Your organization should also be prepared to answer any questions about how accessible your story bank is to the general public. Members of the media, policymakers, STORY BANK TOOLKIT

and other groups who may be interested in getting in touch with storytellers will ask to search your story bank. Think through how your organization will respond to this demand while safeguarding storytellers’ privacy. Can someone who is interested in finding people in your story bank search to find a suitable storyteller without your permission? If a part of your story bank is available to the public, how much information should appear, and what should be kept private? There is no easy answer to these questions. But you should be prepared to respond to questions like this as you share the news that your organization has developed a story bank. However you decide to proceed, always be mindful of the private or sensitive information you may collect in your story bank efforts. Determine the necessary level of privacy your story bank should have Even if you are using a simple spreadsheet like Excel or Google docs, make sure you take every possible measure to ensure storyteller privacy. Sometimes, story submissions will contain Social Security numbers or other sensitive information. More often, storytellers may disclose personal information in the course of a conversation, including medically sensitive information, arrest records, potentially embarrassing details of their lives, or unlisted phone numbers. We will go into more detail on the kinds of information you may encounter in the pieces “How to Develop Internal Comments” (see: Developing Stories) and “Working with Personally Identifiable Information” (see: Collecting Stories). To best protect an individual’s privacy, you must investigate an option that accounts for this kind of information. Even if you’re using a private link to a database, you cannot always guarantee that the link will stay private: Someone may circulate the link widely, especially when it is shared among multiple organizations. For many organizations, the best, most secure solution will be a password-protected database.

2

Building an Infrastructure

2. Determine How You Want to Organize Your Data Another key issue to consider is how you will organize the information that you store. Make a list of the fields you know you will need in order to do your work. This might include first and last name, address, phone number, email, story entry, and notes on the storyteller. Consider adding extra fields that you can sort and search, such as income, birthday, and location where you collected the information. Not all of these fields will be included in a basic database software package, so you will need to create custom fields. For some software systems, you will have the ability to pick whether these fields are open text (a field that could contain any information you desire), pick-lists (choose multiple values in a list), dropdowns (choose one value in a list), or checkboxes. As you explore databases, you may find other fields, as well. One of the downsides to using database software that allows only for open fields is the lack of data standardization. You may end up with too much variety in data entry.

For example, say your organization has an open field for state names. One person enters all states by two letter codes, another by different abbreviations, and a third by the full name. All of a sudden, you have CA, Calif., and California. That doesn’t take into account any misspellings. So if you encountered this situation, it would make it very difficult to get a clear grasp of how many stories you have in California. Any system that relies on open fields will require you to regularly clean up your data. Part of the ease of using a system that allows only for standard labels is that it eliminates the need for that kind of clean up. For example, you could have a drop-down list with all 50 states and would just need to select the one that applies. For other fields, you may want to consider including uniform date and time stamps (for instance, choose a uniform format, like YYYY/MM/DD HH:MM), numerical fields, pick lists, and tags. Determine how you will search for stories One other way to think about data organization is to determine how you will search for stories. Searching for the right story to fill a request is a major component

If your organization provides application assistance and handles personally identifiable information (PII), you should ensure that any database that you select meets the minimum requirements for handling and storing PII. The Centers for Medicare and Medicaid Services (CMS) advises, “If in hard copy, PII should be stored in locked filing cabinets or within locked offices where the paper filing system is maintained. If in electronic format, PII should be stored securely in a password-protected file on a password-protected computer to which only authorized individuals have access.” Centers for Medicare and Medicaid Services, Best Practices for Handling Personally Identifiable Information: Fast Facts for Assisters, (February 2015), available online at https://marketplace.cms.gov/technical-assistance-resources/assister-programs/best-practices-for-handling-pii-fast-facts.PDF .

STORY BANK TOOLKIT

3

Building an Infrastructure

of running a successful story bank. There’s no need to memorize every story in your story bank when you can spend a few seconds performing a smart, efficient search. Databases have varying levels of search functionality. For systems like Excel, you can perform a search through a basic “find” bar. Other databases will allow you to search in varying degrees by any customized fields that you create. After you determine the fields that you will need and the ways that you might organize your data, think through how you want to perform searches. Here are some common issues that arise in searching:

»» Boolean searches: combining keywords or fields with operators such as AND, NOT, and OR. For example, resides in California OR Oregon AND story contains cancer.

»» Searches for a range of dates: for instance, between January 1, 1950, and December 31, 1951.

»» Searches for information about the story creation: for instance, the individual who created the story, the date it was created, when it was updated, and by whom. After you have figured out how you will organize and search your data, you can rule out a lot of options that are on the market. That said, if you find yourself with a limited budget, you may need to compromise on a few areas. However, as you move forward, there are two things to remember:

»» Any database you select should make your work easier, not more difficult.

3. Set a Budget Spreadsheets and databases range in cost from free to tens of thousands of dollars. Be prepared to put in a bit of effort to find something that fits within your budget and has all or most of the functions that you desire. If you are only beginning the process of building a story bank program, or if you anticipate having a small number of entries, it may not be prudent to spend thousands of dollars on a program. We’ve talked to many groups that have been content using Excel spreadsheets or Google docs as they set up their operation. In fact, this can help you determine what your needs and priorities will be later when you decide to invest in something more sophisticated. But if you’re looking for something with more functionality than a spreadsheet, it helps to understand the different options that are available. Software and database solutions come in different forms. Each has different pros and cons, price points, levels of customization, lengths of time required for setup, and levels of support needed. We’ve outlined a few examples of each of the three types of basic information systems: SaaS (Software as a Service), also known as “off-the-shelf”

»» Low to medium effort to get it up and running »» Support is offered through the company »» Cost is low, generally an affordable monthly rate »» Examples include: Highrise, TrackVia, Close.io, Insightly, and CiviCRM

»» You should find a database you want to use. If you find yourself doing everything you can to avoid using your database, you should probably consider switching to something else.

STORY BANK TOOLKIT

4

Building an Infrastructure

Enterprise-level database, also known as a “full-database solution”

»» Medium to high effort to get it up and running »» Requires an outside vendor or contractor to customize the database to your specifications

»» Can be expensive; cost will include contractor plus monthly licensing fees and a support contract

»» Examples include: Sugar CRM, Salesforce, Microsoft Dynamics CRM Custom-level database, built from scratch

»» Contractor builds what you need »» Medium to high effort to get it up and running »» The sky is the limit for the cost; it could easily be five digits

»» This option means someone builds what you need, but you may be stuck with what you get. If your operation evolves, it may be difficult to change the program. Or if the designing company folds, you might be left without support.

Simple Database Vocabulary Here is a starter list of some commonly used terms that you may encounter. Keep in mind that terminology can vary among software. Account: An organization, company, or partner that you want to store in the database. API Connectivity: An “API” is what allows you or other third parties (software companies, web firms) to build websites, apps, or other online functionality that connect with your database. App: Short for “application.” An app is a collection of components like tabs, reports, and dashboards that address a specific need or perform a specific function. You can create a custom app, or in some cases, download apps like these from an “AppExchange.” Audit Log: A log of activity in the database system. These can be simple or very detailed (tracking every activity, change, edit, etc.) on an account or contact record. Boolean Search: A type of search allowing users to combine keywords with operators such as AND, NOT, and OR to produce more relevant results. For example, a Boolean search could be “hotel” AND “New York” to find hotels in New York. Cloud Computing: A model for software development and distribution where the technology infrastructure for a service, including data, is hosted on the Internet. It is accessible from anywhere with an Internet connection. Contact: Individuals stored in the database, often associated with an account (organization, company, etc.). CRM (Constituent Relationship Management) Database: A type of database and/or usage that involves storing accounts and contacts (like a rolodex), with levels of advanced features and functionality (email connectivity, apps, fundraising/financials, project management, etc.) typically included.

STORY BANK TOOLKIT

5

Building an Infrastructure

Custom Object /Custom Field: Custom records or fields that go beyond the “default” or “out-of-the-box” fields, allowing you to further customize your database. Dashboard: A snapshot view of certain information in the database. Database Record: All of the information listed for one particular item (person, place, or thing) in the database. Database: A collection of data (information) on a specific topic stored in an organized manner. Entry: Each piece of information entered for each field. Field: A single category of information that stores data on a given database record. Can be a text box, check box, dropdown menu, etc. Most databases come with certain “default” fields. Household: In some systems, you can create a “household” to group contacts (or families) at a physical address, combining certain levels of information. Sometimes this can be handled by creating one “account” for the family.

For the full Story Bank Toolkit, visit: www.familiesusa.org/story-bank-toolkit Publication ID: 000000001 This toolkit was produced by Families USA •

© Families USA 2015

Match: Using a formula to search/find specific criteria given in a question using one or more “operators” or “connectors,” such as less than, , or words such as AND or OR. Profile: A profile is a group of settings and permissions assigned to a user. It allows staff to have varied levels of control and permissions in the database. Project Management / Activity Tracking: The ability to track project activity and usage by staff members who use a database for certain activities. Report: A report can be a “saved search” or “saved query” for commonly used searches. Search/Find/Query: An operation to locate a specific record(s) that satisfies a statement or statements of criteria. Sort/Arrange/Filter: An operation to rearrange, configure, or limit the records in a database file in a specified alphabetical or numerical order. Think “Sort A-Z, or Z-A.” Template: A pattern or form that is used repeatedly to create each record in a database file. When creating a database, the template is the blank form that comes up each time you add a new record to the database.

1201 New York Avenue NW, Suite 1100 Washington, DC 20005 202-628-3030 [email protected] www.FamiliesUSA.org facebook / FamiliesUSA twitter / @FamiliesUSA