Skip to content

Finding Peace with Your Data: A Worksheet & Mindfulness Practice

It’s not always easy to find peace with your data. How many times have you run away screaming from your computer in agony over a report you needed to create or data that was incorrectly entered? I bet it’s quite a few. Finding peace with data isn’t always a straight path. Often, it’s a curvy path filled with potholes and knotty bushes. Along the way, I believe there can be compassionate pauses where we set intentions, reconnect with our hopes for the work, and engage our team mindfully. Whether you’re cleaning up data in your Salesforce instance or setting intentions for another database project, I hope this worksheet and mindfulness practice (both free downloads, below) will help you move into the work with more awareness and peace.

Read more

August Webinar Announced – Cleaning Up Messy Data with Demand Tools

We had a great turn out for yesterday’s webinar! Thanks to all who participated. Our next webinar in the Salesforce DIY for Nonprofits series is Cleaning Up Messy Data with Demand Tools on August 14. 

Whether your data comes from multiple sources, frequent imports, or manually entered additions, there is always a chance that duplicate records will be created. Do you have concerns about how to clean up duplicates in your Salesforce instance? The Salesforce AppExchange offers several duplicate merging tools, of which the most powerful is Demand Tools from CRM Fusion.

This interactive session will coach you in how to use Single Table Dedupe feature of Demand Tools to identify and merge duplicate records, using live data as an example. You could also be guided through the merging process in your own instance during the session (by prior arrangement).

This webinar will be co-guided by Ashima Saigal, Founder of Database Sherpa and Caroline Renard. Ashima is both a Salesforce Certified Administrator and Salesforce Certified Developer. Caroline is Salesforce Certified Administrator as well as a Salesforce MVP.

Click here for registration information.


Thoughts from a Research Journey with Database Sherpa

A guest blog post by Emily Gremel, Researcher and Strategist

I met Ashima last fall when I led a marketing research workshop for some entrepreneurs she was coaching. Sharing the benefits and values of my field has always been important to me, so I leapt at the chance to share my “gospel” with some blossoming business owners. Little did I know where that workshop would lead…

Read more

Thank You!

Gifts of Gratitude Tour

This week we’ve kicked off our Gifts of Gratitude tour to build a community of Sherpas. This is a fun tour, where I get to have lunch, coffee, breakfast and chat with super cool individuals who have started to build their own communities.

So, what is this all about? Well, I’ll give you a taste, but if you’re want to learn more, you are going to have to have a conversation with me over coffee or tea.

At Database Sherpa, we recognize that many organizations fight with their database more than necessary. Others miss good information just because data is trapped in bad software or old spreadsheets. We are on a mission to help organizations find peace with their data.

We achieve this peace using a process unlike anything data management has seen before. We are more guide than taskmaster, more teacher than consultant. Our unique approach means we are building a community of people committed to compassionate database management. Together, we are proving that databases can have a heart!

We are looking for people to join us. Our journey to Database Sherpa is not paved with big marketing campaigns. It has always been sustained by people like you, who share our values, and more often than not, have experienced our approach firsthand. Together, you create a community of Sherpas by sharing the principles that guide your database practice and referring future clients.

If you want to learn more about how it works, please, get in touch with me at and I’ll be happy to have a conversation!


Karma: What’s it all about?

I’ve been having a wonderful time thinking about Database Sherpa. I am grateful to have the time to develop a process that will work for all organizations. Maybe a little history would help for those new to my concept.

It started about 20 years ago when I was running my business, Hopper Business Solutions. Hopper was the embodiment of my dream to run my own business, be my own boss, and to change the way women were viewed in technology. In the beginning, Hopper provided Internet consulting to emerging businesses, but over time, turned into much more.

In addition to creating new databases, I started modifying existing databases for small businesses and nonprofits—systems created by another consultant prior to my arrival. Whenever I began a project, I always found a mixture of disgust, frustration and anger with these systems. I never enjoyed walking into a place with such negative emotions. I often heard these complaints:
  • “The consultant never listened to us and did their own thing. I don’t know why we have to capture the client’s (shoe size, favorite color, etc.). So we don’t and leave that field blank.”
  • “The reports don’t give us what we need. We fill in all the information, but the reports are missing a lot of information that is in the database. Our data is trapped.”
  • “The consultant never finished the database because we ran out of money (or worse, they stopped helping us and moved onto another project). Plus, they worked too much on what they felt was important, and not on our immediate needs.”
This litany is probably no surprise to organizations that have probably at least one such pain point with their former or current system. Let me just say this: It’s NOT just the consultant’s fault.
How can I say this? When I began working with unhappy clients, at some point they say that they had forgotten to mention something to consultant, emphasize the deadline, or take control of the project when things got out of hand. Blaming the former consultant was an easy out.
But, these are mistakes that happen. Even to the best consultant. I wondered, what could we do to make these complaints a place in the past? How can we, as consultants, pass on our knowledge and skills so that the client is now capable of doing the work needed? How can the client be put in the driver’s seat and the consultants be the guide? How can we make our clients happier—and more productive—than when we began with them?
My search for these answers lead to the birth of Database Sherpa where we have a simple value: Bring compassion and joy to our clients, all the while helping them achieve good database karma. (Thanks to DVQ Studio for that fun word combo).Yes, I said JOY. Database work can be tedious and boring. Sometimes it’s even downright frustrating. There is enough frustration in the world, and we have a strong desire to change that. So we approach every project with a positive attitude and encourage lots of laughter and fun to bring back the smile! Now, about that database karma thing, I’ll get to that in a sec….
So, what brought about this thinking about going the extra mile to bring joy into work? Well, recently I’ve been in dialogue with another consultant who has also gone down a similar path, albeit for much longer than I. She has lots of great stories and results, and she’s quite a guru who is becoming a dear friend.She feels it’s important to meet the client where they are at the time they contact her. She told me, “I want to work with clients whose missions I feel strongly about, that I want to support. It’s important that I meet the client where they are, not where I am.” She’s quite compassionate to her clients, and I am sure I can learn more from her as time goes on. And I am in complete agreement with her. We could all learn a thing or two about compassion! She makes a compelling case that makes a lot of sense to me.

We should all help those that reach out to us. Give them the guidance and tools they need so that they are more capable and empowered to drive their mission in the right direction.

But, before you run off sharing your wisdom with everyone you cross paths with, I’d like to offer a caveat. While it’s important to help organizations that to seek change, it’s also critical to make sure they align with your core values.

A key core value at Database Sherpa is to help build good database karma for organizations (I said we’d get back to that). What is this database karma and how does it work? Well, it’s not the karma from the eastern philosophies, or from the TV show, “My Name is Earl.” It’s about destiny to a small extent, but karma is more about action than anything. (And as an aside, I’d like to say there is really nothing “good” or “bad” about karma; it just is.)

Taking this concept one step further, we also believe you cannot outsource your karma. You can’t blame your karma on a long-gone consultant. Good database karma is the result of organizations investing energy to create its database and taking ownership of its long-term maintenance and evolution.

In order to bring positive database karma to organizations, it’s crucial that they be open, be willing to spend time and learn, and be capable of making their database work for them. Good database karma is not as simple as importing data from a spreadsheet. It requires being patient, practicing compassion, facing your fears and doing it “self mommy“.

So, my friend will continue to exhibit compassion for her clients, encouraging and guiding them—even after they’ve started working with her. (A workstyle I greatly admire.) Compassion can have a powerful outcome. It could change the world by making us active, rather than passive learners. (If you read my last post about compassion, you’ll see why I’m such an idealist now.) Ultimately, we desire the same outcome: To make our clients successful with their database systems and increase their knowledge.  My friend has already achieved that, achieving great success and admiration from her clients. That is a wonderful feeling and one she is very proud of.

As a Sherpa, I dream of a day when my client will outshine me and go on to do great things in the database community. I bow deeply to my new friend who has given me food for thought and opened my eyes to other possibilities.

Hopper to DBSherpa

Moving from cloud to cloud

Yes, I sold my domain name — I wasn’t looking to sell, but an opportunity came along in which I couldn’t refuse. Thus, began my transition in the cloud. I needed to move this sold domain name ( to another domain name (, all of which was in the cloud with Google Apps.

My first step was to ask my colleague about his recommendations as well as look online at the various tools. I was hoping it was really simple. Something like this image:

So, I did learn it was not that easy. Although I was moving from one cloud to another, I was staying in the same cloud system (Google Apps). I was not moving to another online product, but rather staying with the one I already know. You might remember my previous post about the condo analogy. Basically, I was moving from one condo to another. I wasn’t changing anything at all. You would think I could pack up my data (luggage and furniture) and just move!

Well, it was kind of like that, but it is not as easy as that image portrays. It’s also not as difficult as it used to be either. Just so you know, it took me about 6 hours to complete the entire transition (condo move). Just to give you a sense of what I was moving, it was two email accounts & one document and calendar account.

Most of that time was waiting for files to move (maybe that’s the movers I hired!), let me explain my steps (this is not a how-to guide, there are lots of those out there, it’s more like what I did and what I found):

  • Downloaded Mozilla Thunderbird. Retrieved all the email from my account from Logged into the email account. Manually copied each folder (found in Thunderbird) from the to the email account. This ran overnight as the process was quite a bandwidth hog. All my folders copied over but I left the spam alone! This process took the longest and ran a few nights with a few restarts thrown in when my computer froze.
  • Exported my calendar from Google Calendar ( and imported into Google Calendar ( Easy and quick.
  • Downloaded my Google Docs to my hard drive (each category was exported separately to create unique folders). Expanded the zipped files into folders (the categories). Imported into my new Google Docs using the special import folder function which creates a category. Worked great except for those documents that were in multiple categories which were imported twice. Thus, I needed to clean up my newly imported data. Opened my account and account and compared manually. Took a bit of time, but it was do-able.

Some things that I learned after the import:

  • A feature that I like with Google Docs is the ability to see what I have worked on recently and what I worked on a couple days ago, etc. I didn’t realize how much I used that information when working with my document until I didn’t have it (isn’t it just like that?!). Well, when I imported the data, that information is no longer there. I’ll have to build that up again. Sigh!
  • When exporting the Google Docs, they came to my computer as docs, excel spreadsheets, etc. When re-imported, the formatting did change a bit. Not a perfect process, but close enough.
  • All my special markers and such with my email came across just fine in the new email account. Thunderbird did a great job of moving files back, it just took a long time!
  • It was helpful to move the Sent Mail from the old account to the new account. I often had emails in that folder that were important (as I realized when digging around for an email I sent out).
  • I used tasks and those did not import. There is currently no way to import tasks from Google calendar, so I just printed out all my current tasks and hand entered them into the new calendar tasks. Worked okay, but I lost all my completed tasks. I really don’t care about that though.

All in all, moving from cloud to cloud wasn’t bad at all! I must say, I don’t want to do it again anytime soon. Then again, I don’t think most people liking moving in general.

Until next time friend….

    Being in the Cloud.. You can take it with you!

    This post is really musings… ramblings… please bear with me on this, it might make sense in the end.

    Just the other day I had a wonderful conversation with a new client who left the workforce after her kids were born, just during the cusp of mainframe transitioning to the client server model (she’s a fellow techie. YAHOO, another female techie!!). Now, her kids have grown up (the youngest heading to college) and she looks across the IT vast land and sees something very similar to what she left.

    The reality is, the cloud technology embraces both the mainframe model (centralization) and the client server model (de-centralization). It reminds me of the harmony between the muscular energy and organic energy in yoga. The balance between them makes a pose feel wonderful! Just like I’ve fallen in love with yoga, I’m falling back in love with technology. In particular, databases. So much more than Access or FileMaker Pro. It’s just wonderful!

    So, as she and I were discussing the topic, an analogy came to me as we discussed the multi-tenant model of (she was quite concerned about her data being mixed up with others AND security, remember, she comes from a very centralized place) So, I had her visualize an empty condo. The rooms are all laid out: outlets, cable hook up, washer and dryer hook ups, water, etc. The layout is all there for you. Now, all you need to do is add your furniture (data) and maybe a little design (paint on the walls, rearrange things slightly), but the basic floor plans remains. The condo association maintains the building, all you do is live in your space and call when there are problems (help desk or forums). You have your own secure space with a key and lock (password and encryption). You’re able to rearrange as you want and you can even change some fundamentals if you get condo association approval (adding your own code to customize and build out Salesforce). Then, when you want to move, you pack up your furniture (keep in mind, the paint stays on the wall, it’s temporary anyway, as does any build out) and you find a new condo (like moving from to another cloud based or maybe internal database). It’s like that with Yes, you can take your data with you! You’re not stuck with them forever. Can you imagine? Changing software systems that simply? Yes, it takes time to get things in order, but hey, you are not beholden to any one company! What a wonderful and freeing feeling.

    So, what we have now, is the ability to do our work using the best of all worlds. The client server model (yes, I can download my data, work off my servers at the office, etc) AND the mainframe model (having access to super fast machines, centralizing the hardware maintenance for the heavy lifting, etc). And, the cherry on top is that we can MOVE SYSTEMS. I can take my data anywhere I want. This is just wonderful and feeds my yogic mentality.

    NOTE:  I have another post coming about moving from Google Apps to another Google Apps (different domain name) and the process that took. It was not easy, but it was do-able.

    Patience is critical to learning and teaching!

    Recently, I had breakfast with a good friend, mentor and supporter. While we were chatting about politics, the state of our economy and other light topics (HA!), we brushed up on her organization’s implementation (they were in my first cohort). They’ve lived with this system for about 18 months and it’s been serving their needs. During this time, my friend (who happens to be the executive director) has had a few ah-ha’s that I think are very relevant and important to share:

    • Don’t throw the database out with the bathwater! It’s really true. She recounted an example where the database did not have a specific field. During the designing phase, they were capturing the work done by the volunteer, hours and client served. No volunteer name was captured. What they learned, as the system was put into the flow of the business, is that the volunteers wanted follow up with clients but the staff couldn’t find volunteers since the names were not put in the database. She laughed and said, “before, I would have said let’s throw this database away. It is poorly designed!” But now, she realizes that THEY CAN FIX IT. They are empowered by being able to make the changes on their own. There is power with this sense of freedom and realization that systems are made to be flexible and fluid. Organic!
    • Reporting is more than just numbers. She laughed as she told me about their reporting mechanism. Someone would send a request to the system administrator who would create the report. Pretty simple, but what they realized is that they were not providing her a good definition of their needs. What they saw were that the numbers looked wrong in the reports. Now, they knew the data was entered correctly. So, as they dug deeper, they realized that it’s not simply pulling numbers from the system but really understanding the basic underlying structure of the database. Here is an example of what I’m talking about: getting a list of active clients should be easy, right? It’s just a list of all the contacts in the database, right? But, when the requestor is given the list of “active” clients, he/she realizes there are some “inactive” clients in the list. And, as they dig into the system to understand why the “inactive”clients show up, they realize that the definition of “active” client was not properly given to the system administrator. So, what would have been better is the following: I need a list of contacts that have had activity in the last 12 months. This gives the system administrator the ability to pull the data appropriately from the system. But, here is the thing, if the requestor doesn’t understand how the system was built, they cannot even begin to know what to request. Since this organization created their database, their understanding is much deeper. The requestor and the system administrator can have a conversation in data lingo and understand each other. It’s wonderful and amazing to see this growth and learning.

    As she recounted these stories, I could feel myself swell with pride for this organization. I am so very proud of how far they have come with their education. The education that they have given themselves is more than I could have ever hoped for… it’s simply amazing what they have managed to do themselves. It goes to show, if you give individuals the education they need and crave, they will surprise you.

    This organization has come such a long way in their understanding. and it happened on their terms and in their time. That is the beauty of teaching database development in this way, it teaches you patience, persistence and focus. Through this comes knowledge and through that will come wisdom.

    It’s a privilege and honor to be given the opportunity to teach and learn beside these individuals. It’s very humbling.

    Beginning again…

    Being a yogi, we learn that we are constantly beginning again, thus, I begin again this blog. My musing will be focused on databases, yoga, women in technology and general thoughts about society.

    So… with that, I bring you my first post for the year and hope to post on a regular basis (note, I didn’t give a time frame here, so I don’t box myself in…. ah the beauty of yoga).

    Our lives have taken a sharp turn, and it’s wonderful. A new being in our lives fills us with joy and much work. I’ve decided to begin a new chapter as full-time parent and part-time database consultant. As you might know, my focus has been with and working primarily with nonprofit organizations. My goal is to teach rather than do the work for the organization, thus building the organization’s capacity to continue to maintain and manage their own database. I would say that mostly it has been a success, by mostly I mean that sometimes I find myself going back to the place of “doing the work” rather than “teaching how to do” primarily because it’s easier for me and the person doing the work at the organization. I do catch myself, which is good, and put it back on them to finish it up.

    It’s been at least two years since I have begun this work and there are a few things that keep popping up to me over and over again. These are some of those issues/things that have come up:

    1. Turn over of staff: This has probably been the most challenging issue to deal with in this teaching model. I have been of the mindset of teaching two staff at the organization (thus one is a back up for the other), but have found on a couple occasions that both individuals leave the organization, leaving a gaping hole! I’ve had one organization actually say to me that they wished I had built it for them and then they could just have come back to me. Oh well, I guess the point is that 2 in 20 isn’t bad. But turn over is an issue that I need to address somehow…. I’m still mulling this over. I’ll get back to you later on this one, but I’m open to any suggestions you might have.
    2. Understanding process: On more than one occasion, I have asked someone who works at the organization how they manage a process (whether it be intake of clients or managing events or accepting donations) and I get this blank stare and sigh. For example, when asking the person who manages events, “how do you do it?” I get the big sigh and then a stream of consciousness on how they do it. Nothing solid, a lot of ums, ahs and such. There process is called “by the seat of their pants”. This is always a sign of problems for success with a database, BUT, there is always a solution. When this happens, I usually have them diagram the process for me (usually a handwritten flow chart or steps) with a detailed explanation (where I can asks tons of questions). This does get us closer to understanding their “stream of babble”. And, in the process, they are helping their organization to document and clarify processes. I love this part of the design phase! It’s so… so… neat and tidy. I think database people like neat and tidy (although we often get curve balls, but that’s another story for another day).
    3. Focus: In this education model, I’ve found that many individuals wander into other territories. What started out as a volunteer database ends up being a volunteer, donor and client management database. Which isn’t a bad thing, in the long run, but NOT TO START. It’s important to focus in the beginning because of the learning and doing process. Since I am a yogi, this is an important learning for me and for my friends learning with me. I always try to bring them back to the focus and remind them that the other pieces will be waiting along the sides. But, to stay focused on this for now… until you are ready to move on. And, you’ll know when that time has come. But, during this beginning phase, focus.
    4. Time: As a young yogi, I always believe there is more time, but I forget about roadblocks that might come up (such as other work, a special event, illness, etc.) thus I ALWAYS underestimate the time it takes to get through the beginning stages of learning. I am learning. I am getting better at this. After all, it’s not a perfect science and we all (come on, you know you do this too) guesstimate the time.

    So, these are some of the key things I have learned since beginning this journey in combining my yoga practice with database development. I am so excited to continue this path and hope you will join me on my journey!