Behavioral Security - Team Skillset Assessment and External Vendor Checklist
In today’s edition of The CRM Tea’s Securi-tea series, we will be continuing our discussion on behavioral security for your CRM. We will go over a few checklists for assessing your internal team and external vendors. If you haven’t already, consider referring this newsletter to a colleague that you believe would find the content valuable.
Assessing Your Salesforce Team's Skillset
The proficiency of your Salesforce team is a key indicator of your platform's success, as well as your platform’s security. Are you running on a team of juniors, experienced administrators, or certified developers? Understanding the skill and experience level of your team helps you identify gaps and plan for future growth.
This knowledge is crucial for scoping new projects, managing expectations, and determining whether you have the in-house talent to tackle complex integrations or whether you might need external support. The maturity level of your team is also an indication on whether or not you have the skillset needed to properly secure your CRM. The below checklist will have you consider:
Certifications within your team
Ambiguous working conditions (What do I mean by this?)
Evaluating previous project delivery by teammate
Evaluating your team’s business acumen
Certifications
What Salesforce certifications do your team members hold?
A lot of people do not think certifications add value, and I disagree. Certifications (e.g., Certified Administrator, Platform Developer I, Application Architect, etc.) provide a standardized benchmark of knowledge and expertise.
Does somebody need a certification to be able to perform a given job? Not necessarily. Does having a certification indicate to the hiring manager someone has demonstrated classroom knowledge of a given area of Salesforce? Absolutely.
Benchmarking the amount of individuals with different certifications can give you insights on where you have certain skills and where you may have gaps. This also goes for non-Salesforce owned certifications, such as PMP, or TOGAF.
Are you interested in an infographic comprehensive list of Salesforce certifications? Feel free to reply back and let me know your interest in such a graphic!
Working in ambiguity
As it relates to ambiguity, would you rate your team as junior, mid level, or senior?
I include this section as it really impacts the capacity/throughput of how much your organization can deliver for your CRM. These next few paragraphs about evaluating your team’s current experience level is less about their experience with CRM, and more about their ability to work in ambiguity.
What does this have to do with security of your CRM? Well… you will run into scenarios where junior employees might not be forthcoming about what they think is an issue, such as a sales rep exporting all the data of your org (real scenario I’ve run into).
Understanding your team’s maturity profile is critical to being aware of and getting ahead of problems.
Junior team
A junior team will require frequent check-ins and direct guidance. T
hey will often look for answers from you, without problem solving themselves.
Their mindset is often short-term, centered on the immediate task assigned to them.
They have low autonomy, will ask for permission, or validation before taking a new step.
With developers, they’ll often get stuck or just stop working altogether until they receive specific instructions, with ambiguity being viewed as a roadblock.
Mid-level team
A mid-level team I view as more of doers and a problem-solvers.
They’ve mastered foundational skills, and can take ownership of their work.
They can be given a problem and solve it, even without a detailed plan or instructions.
You will notice increased independence, less supervision, and the ability to manage their own workload.
They will begin to understand how one can improve processes to gain efficiency, and may even suggest better ways to handle existing exists.
They won’t freeze in ambiguity, will instead ask clarifying questions, and formulate a plan of attack, and even identify what information they need to begin planning.
Senior team
A senior team has the strategic leadership to not just complete tasks or solve problems, they define them.
The work of a senior team has a broad impact on a department, business unit, or entire company.
You will notice they operate with complete independence, interdependently, are self-directed and don’t need to be told what to do, they’ll often tell you what needs to be done and their plan for accomplishing this.
They have long-term goals and a high-level perspective of where they want to bring your Salesforce org to influence different KPIs/OKRs.
They’re able to mentor and influence junior and mid-level employees through influence, rather than authoritarian leadership styles, shaping the direction of the team with guidance.
When given a vague goal from a business stakeholder, they will define the problem, scope out projects, identify when they need additional resources, and create a clear path forward for others to follow.
Project History
When you are evaluating a candidate or teammate’s previous project experience, go beyond the “What” and get to the “How” and “Why”.
Don’t just ask “what similar projects have you completed related to our organization?”, ask scenario-based questions like:
Can they articulate the business problem their project was solving?
What was their specific role and contribution? (e.g., "I led the data model design," or "I was responsible for all of the declarative automation.")
Walk me through your process for gathering requirements from a non-technical stakeholder.
How do they handle large data volumes in their projects? (e.g., use of indexing, batch processing, data archiving).
What security model did you implement? Can you explain the roles, profiles, permission sets, and sharing rules used in a previous project?
Describe a time you encountered a data quality issue. How did you resolve it and prevent it from happening again?
How did you manage configuration changes and deployments? (e.g., use of change sets, managed packages, etc.).
What experience do they have with integrations? (e.g., REST, SOAP, Platform Events).
Walk me through a custom LWC you've built. What was the purpose of the component?
Business Acumen
You should aim to go beyond just technical knowledge of your team, so that they can apply real-world knowledge to real-world business challenges.
Some great questions I like to evaluate my team against include,
Can you describe a complex business process you've automated on the Salesforce platform? What was the original problem, and how did your solution improve it?
Imagine a business user wants a new custom field on the Account object. How do you decide whether to use a formula field, a roll-up summary, or a new custom field with an automation?
How do you explain a complex technical solution to a non-technical audience, like a sales or marketing leader?
Discuss the importance of governor limits. Can you give an example of an Apex or Flow solution that could hit a limit and how you would prevent that.
How do you evaluate and implement solutions from the AppExchange? What are the pros and cons of using a managed package versus building a custom solution?
The next section will switch gears from evaluating your internal team, and switch
Vetting External Vendors: A Proactive Approach
Working with external vendors introduces new variables into your security and operational framework. Before you share data or grant system access, do you have a formal process and a checklist to vet them?
A thorough vetting process should evaluate their security practices, data handling policies, and technical competence. This due diligence ensures that your partners meet your standards and don't become a weak link in your security chain.
A well-defined checklist streamlines this process, ensuring no critical step is missed. Here is a starter one you can utilize:
Installation Vetting & Approval Checklist
Is there a clear, documented business need for this app?
What specific problem does it solve that cannot be solved with existing Salesforce functionality?
Have we identified all key stakeholders (e.g., Sales, Marketing, Finance) who will use the app, and do we have their explicit buy-in?
Have we reviewed the licensing costs, potential implementation fees, and ongoing maintenance costs? Is the ROI clear?
Have we confirmed there isn't a native or existing solution that already meets the need?
Security & Compliance Checklist
Has the vendor provided a recent security audit report (e.g., SOC 2, ISO 27001)? What is their process for handling security vulnerabilities?
Have you looped in your GRC, infosec, legal, or other related teams?
Can the vendor provide a report from a recent third-party penetration test?
Where will data be stored? Is it on Salesforce, or is it transmitted to and stored on an external server?
Do you have data residency and encryption policies/laws to consider?
What level of data access does the package require?
Does it ask for Modify All Data permission or other broad permissions? Is this access level truly necessary for the app to function?
Does the vendor comply with relevant industry regulations (e.g., GDPR, HIPAA, CCPA)?
For our next article, we will pivot into integration governance, and reviewing packages prior to installation. Have any questions? Don’t hesitate to send me an email at [email protected]
Don’t forget to share my newsletter with your colleagues if you found today’s article valuable.