project risks

  • Cutting the Clutter: Maintaining a Clean Salesforce Org

    Maintaining a clean Salesforce org, doesn’t need to be a battle. Recently, I was watching a great webinar by Kelly & Leanne entitled ‘Cut that Clutter‘. And it got me thinking about how the problems faced by a cluttered Salesforce, and how it can easily consume an Admin’s time and effort. And it not only affects us as Admins, but also our end users! So in this post I am going to recap some of the awesome tips shared in this webinar, and also see offer some additional FREE tools to tackle the problem that so many of us face!

    The War Against Clutter

    Ok, ok. I admit that this header is full of hyperbole.

    Maintaining a Clean Salsforce, shouldn't be a battle...
    Don’t raise the white flag, in the war against clutter!

    But a cluttered Salesforce creates a lot of frustration and anxiety for me. And I assume most it does for most of you reading this too! My personal vendetta against clutter drives me to ensure I am always improving the org for my end-users…

    I have previously written about how we started to tame the Technical Debt beast haunting our primary orgs and removed over 2 million records from an org (hint: very manually).

    But there is still so much to do…

    It is a seemingly never-ending fight. But as Admin’s we are always looking for tools and resources to help us in our day to day Admin Superhero duties. And to help us in maintaining a clean Salesforce org…

    Cut that Clutter! – The Recap

    Now before we get much further. If you have a spare 30mins I strongly recommend that you watch the webinar as I am only going to briefly summarise it here…

    The session covers the Three-S’s. These are the primary areas to focus on, to ensure your CRM is kept in tip-top shape.

    • Security – making sure you know who can see what in your CRM
    • Structure – does the setup of Salesforce ensure data security and meet any data governance requirements
    • Strategy – how to plan and scale while ensuring you don’t have to keep doing ‘big clean-ups’ each year

    If you want to hear more, then please check out the video.

    Cut that Clutter: Resources mentioned

    Next up, the ladies mentioned some great tools to help you in maintaining your Salesforce org.

    From Salesforce:

    • Salesforce Optimizer (aka Optimiser in non-US/Canada countries ūüôā ) – I am in LOVE with Optimizer reports. It is such an amazing tool to help you analyse and understand where the Technical Debt is likely to be hiding within your org. This should be your first port of call, in maintaining a clean Salesforce. That is how much I love it!
    • Security Health Check – helps you understand any vulnerabilities you may have within your Salesforce. This covers areas like Password Policies, Critical Updates, etc.

    From AppExchange:

    • Field Trip – this tool is one I install in every org I have managed now for a number of years!! It is a great tool to help analyse and understand just which fields are being populated and used by your end users. It is worth noting, that if you have a field that is always updated automatically by a trigger/workflow… Then it will obviously show as being used, even if that trigger/workflow update isn’t actually required. But overall it will help you understand your org in very tangible way.
    • The Permissioner – can help you when mass assigning/removing Permission Sets from your users.

    From Trailhead:

    Additionally the ladies have set up an Admin Trailmix.

    This covers a number of modules covering: Salesforce Profiles/Permission Sets, User Authentication, Data Quality, Data Management and finally Reporting & Dashboards.

    Help with maintaining a clean Salesforce org

    Extra, extra! Two more tools to add to your Salesforce Cleaning toolkit…

    Now for the bonus round.

    There are always so many tools and ideas out there helping admins when maintaining a clean Salesforce org. And I am only skimming the surface with these next two tools…

    Compare Permission Sets & Profiles

    When watching the webinar, albeit not live, I started shouting at my screen.

    During the Security section, there was a point around Profiles/Permission Sets. As an admin it is a mammoth task to compare all profiles/permission sets and what they might grant access to within your org. This can be kryptonite to Salesforce Superadmins…

    There was a recommendation to switch off Enhanced Profile View, and then compare the permissions… But why do that? Especially, when there is a secret weapon at your disposal?

    Perm Comparator by John Brock is that secret weapon!

    Seriously… More people need to know about this tool! And I am not even on commission! ūüôā

    Stop duplicates in their tracks…

    Salesforce hasn’t always been an admin’s best friend when it came to cleaning an org…And without getting all ‘back in my day’-ish…

    But there was a time Optimizer, Security Health Check and those tools simply didn’t exist.

    There was also a time Salesforce didn’t have an easy way to prevent duplicates… Admins had to either buy other tools to identify and manage duplicates, or create complex formulas and validation rules to try and prevent exact match duplicates.

    But when planning your strategy for maintaining a clean Salesforce, you should investigate the in-built duplicate management tools from Salesforce.

    After all, what good is cleaning up your security (profiles, access policies, passwords) and clearing out fields you don’t use any more – if your end users are still swimming in duplicate records?!

    The in-built feature will take care of the basics, but depending on your use case, there may still be a reason to buy a tool like Cloudingo or DemandTools (just to name a few).

    What is in your toolkit?

    De-cluttering your Salesforce can be so rewarding!
    De-cluttering can be so rewarding!

    As I mentioned I only skimmed the surface here… And this is a topic I can (and will likely) write more about in the future. I have rambled more than enough for now…

    So to wrap up the post, feel free to add any other suggestions or recommendations for your ‘Cleaning Salesforce Toolkit’ into the comments section below.

  • How to migrate data into Salesforce

    There comes a time in every administrator’s life, where you might have to migrate data into Salesforce.  Why is that important?  Data is the core of any CRM platform and has the power to become a blocker for your customers and/or internal users!

    A request to migrate data could be as simple as someone asking you to import data into Salesforce from a spreadsheet.  Or it could be due to the retirement of another system.  Even a merger/acquisition!  But when the time comes, you will need to be able to really get under the hood to understand the data and create a data migration plan.  Because without a plan, migrating data can become a massive risk to any project.

    Over the next few weeks, I am going to dive into a number of topics relating to all things data migration.  YAY! I hear you screaming! Also please feel free to share any of your experiences in the comments below, as with all things data migration there is always plenty to learn!

    So let’s get started and dive into the key things to plan for when you are attempting to migrate data into Salesforce.

    Everyone loves data

    Data is the lifeblood of any business.  And your data in your CRM is no different.  Good data can empower any business.  While on the flip side, data can also become a blocker for your teams when not managed well.  But the good news is this shows your users have something at stake in making it better.  These are the same people who can become your data champions!

    To further the point I am trying to make around identifying your stakeholders. ¬†Your end users play a big part in advising you on what the data actually means (for them). ¬†And it is here you will also need to identify other potential stakeholders. ¬†Does the data have an impact on sales reporting? ¬†How about on your company’s financial reporting? ¬†Or is it used to help serve or fulfil your customers.

    Everyone loves data! Source: dilbert.com

    I have a question for you ma’am!

    As part of any data migration, you will need to get up to speed on understanding the data.  Understand and interrogate the old data.  Analyse it.  Test out any assumptions you might have.  And also think through how you want the data to look once the migration has been completed.

    This is a time you are going to need to ask a lot of questions and ensure you (and your stakeholders) fully understand the definitions being used.¬† If there is something that doesn’t make sense, ask questions! ¬†Questions are your friend!¬† Really drill down and confirm your understanding. ¬†Leverage the experience of your stakeholders, bring them along the journey too. ¬†And make a note of these questions are you get answers.

    One lesson I have learned over many data migrations is no-one has all the answers unfortunately.  Most times you have to really dive into the data and test what you have been told.  This is one area that is a big risk to any project and can end up causing a lot of pain no matter how well planned!

    I have been on the tail end of a few really complex data migrations. ¬†Even with the best planning and stakeholders, there has always been an inconsistency somewhere in the data which has you screaming ‘WHY!!!!’ ¬† Especially if you are dealing with an older CRM! ¬†(but that is a story for another time!).

    The point I am trying to make is it has been down to the project team to really untangle and interrogate the data to make sure it makes sense.

    Prepare, verify, test

    One you understand the data, you can plan to migrate the data!  There can be a lot to think about at this stage.

    In your preparation, you need to map out where you want the data to go.  Are there new fields created to support the migration or are you mapping to existing fields in Salesforce?  Does the data-type match (eg does a number field map to another number field)?  Do you have any validation rules or mandatory fields that might get in the way?  If so what is your plan to mitigate that?  Do you update the data before you move it?

    Some of the biggest problems I have encountered in a data migration have all stemmed from a lack of full testing in a sandbox.

    If you have access to a sandbox, plan out your testing.   Even if you have Professional Edition, you have access to at least a Developer Sandbox (check here).  Part of your testing needs to include verifying the actual data.  Does to match what you had in the data source?  Do any lookups to other records link up correctly?  Are the number of records the same?  All those questions you wrote down while understanding the data, can be very useful in the testing phase.

    I have thrown a lot of questions around there, but hopefully you get an idea of some of the things to think about in this stage.  Testing is another great time to re-engage with your stakeholders.  Heck, even get them to login and run a few test scenarios on the migrated data.

    Once you have tested and verified your data, you can start planning the go live and move into production!  Your almost there!

    Step back in time

    migrate data, but only with a backup plan
    Back to the Future

    With the actual data migration into a production / live system, you should plan in advance on how you intend to roll back any changes you make.  Even after testing in a sandbox, there could be something which causes you to halt the data migration.  And if that happens, you need to be able to restore the system to how it was before you started.

    Take a backup, run reports, hold onto the import files from Dataloader.  Whatever it is, just know how you can go back without causing further issues.

    This is doesn’t need to be overly complex, but it will¬†depend on the size of the overall size of the data migration. ¬†Sometime it can just be a simple plan to say ‘if this happens, this is how we move forward’.

    Press the button & migrate data!

    This is the fun part, and all your planning comes together.  This is where you start the migration and hopefully completed the migration as planned.

    Once you have migrated the data into Salesforce, test and verify again.  Repeat the steps you did after you loaded the data into the sandbox.  Test and verify, test and verify!

    Are you finished yet?  Good.  But did you disable any workflows/validation rule/mandatory fields?  Did you remember to turn them all back on?

    And finally, and most importantly. ¬†Have you communicated the successful data migration out to your stakeholders!? ūüôā

    Do you have any lessons learned?

    As mentioned at the start of the post, I feel there is always soomething new to be learned everytime you migrate data.  One of the projects I am working on at the moment is pushing me to learn something new every day! (More on that in another post though).

    Sharing is caring ūüôā Do you have any tips or things you like to plan for?¬† Share them in the comments section below!

  • Identify project risks

    As a Salesforce Admin/Consultant/Developer, you will often be involved in projects or initiatives. ¬†In this post we will take a look at identifying and managing project risks. ¬†Why? ¬†Because in a project, risks can cause major problems and lead to roadblocks that you simply can’t get around.¬†

    What is an acceptable project risk?
    What is an acceptable project risk?

    In a previous post¬†we talked about why setting a roadmap is important. ¬†It allows you to engage with your users and stakeholders while¬†involving them in defining the Salesforce strategy. ¬†(You have setup a roadmap now, haven’t you? ¬†:-))

    But once you have planned what and when things should be delivered, now we need to focus on identifying potential project risks.  How do you judge what is an acceptable project risk?  And how can you manage and then mitigate these risks?

    What is a project risk?

    Risk is an everyday occurrence in our world and it is subjective from person to person. ¬†In an extreme example, some people would take any perceived risk and jump out of a plane (hopefully with a parachute), while others wouldn’t even dream of it! ¬†The point is risk is all around us and we make decisions everyday, even if subconsciously, to say ‘I am prepared to take that risk’.

    Project risks are the same, things that you or the team can see that may potentially cause issues later on. ¬†Now I have used two key terms in that sentence. ¬†Risks and issues…¬†What is the difference?

    In its simplest form a project risk is something that may happen during the project. ¬†And if it does it occur, it may have an adverse effect on a project’s delivery. ¬†That can be either what is being delivered, the timelines for delivery, or in extreme cases can block delivering anything. ¬†Risks’s are potential/future focused. ¬†For example, a risk to a project could be that after the project has finished, end users don’t use what was delivered to them.

    An issue on the flip side is generally something that is current or happening right now. ¬†An example of an issue would be unexpected sick leave. ¬†This could disrupt timelines and what was planned today can’t happen.

    So how do you capture project risks & issues?

    project risks vs reward
    Even though there will be risks, sometimes the reward is worth it.

    Now imagine you were on ship trying to reach your arrival port, you want to arrive on time but there are a number of risks you need to consider.  What route to take?  Are there any storms/icebergs in your way?  Or would you just set sail and hope for the best?

    By identifying any risks and issues, you can then come up with a plan to mitigate it.  Allowing you to avoid extra the time and costs hitting an iceberg would cause

    It isn’t an exact science but the key is to take time, stop and think about it. ¬†Think about what you are trying to achieve. ¬†Risks¬†are¬†related to what you are trying to deliver. ¬†What could derail the project? ¬†Is it related to resources (access to certain people at a specific time in the project)? ¬†Are you at risk of other systems / integrations causing issues?

    You can keep these simply enough in an Excel/Google Sheet that the project team has access to. Everything you brainstormed,  enter down as a new line.  The key is to do it, start it early on in the project life cycle and to continue doing it throughout the project.

    Once you know what the risks are, you can then take measures to address them.   This allows you to plot a course around any risks and hopefully avoid them becoming issues.  As an example, need specific involvement from a subject-matter expert at a certain phase?  Plan for it and book them in.

    Get creative

    Draw a Treasure Map - great way to identify project risks
    Draw a Treasure Map – great way to identify project risks

    When defining risks (either good or bad) you could hold a session with your key stakeholders.  Have a project kick off and discuss the objectives of the project and what does project success look like.

    For something a little different, get creative.

    One session I have run a few times with stakeholders is to split people into smaller groups of three or four people. ¬†Then get people to draw out a treasure map with labels on it. ¬†Draw the risks as circling sharks, a skull island or a ship upon the rocks. ¬†And the treasure is the project being delivered after circumnavigating all the risks. ¬†But the aim is to think about problems creatively, I have even seen a group draw a space ship making a journey through the galaxy…

    I find it helps get people out of their comfort zone and shifts their mindset from their normal day to day work.  You can then also ask the groups what are some ideas to mitigate the risks.

    After the sessions add the risks to your spreadsheet (if you haven’t got them already). ¬†If your group came up with possible mitigations, also make note of this as you can build on it as you start your project.

Back to top button