The decisions made by the first consultant or freelancer are critical. As someone who freelances as a Salesforce architect, I've seen how these decisions shape the entire system. Here's why that initial consultant is so important:

The first consultant lays down the processes, and what I mean by processes are mostly automations. If these processes aren't built on common sense, it's hard to change them for several reasons.

Common sense is an architectural mindset where you intuitively determine what makes sense and what doesn't. Typically, one can discern why something makes sense or doesn't, and then the reasoning behind it follows.

Even a small change in large enterprises requires a lot of communication and preparation from different departments. For example, let's consider an ongoing process where updating a field currently results in the creation of a new record. Now, if we want to modify this process so that instead of creating a new record, other fields on the same object are updated, it might seem like a straightforward change. However, in reality, several actions need to be taken in large enterprises to implement this modification effectively.

• User adoption: The business needs to communicate this change with users, training them not to expect a new record but rather a field update.
• Data migration for previously created records: Previously created records and its values need to be migrated to new fields on the same object. This can be accomplished either through a batch job or manual migration, mostly during non-working hours to avoid operational disruptions.
• Data pipeline changes: The data science team needs to be involved in adjusting their pipeline accordingly after the migration.
• Reporting changes: The data analyst team needs to be informed of the changes so they can identify which reports need modification.

Now, consider a scenario where the refactoring process involves different flows, triggers, records, and fields. The level of coordination and preparation required is substantial and extremely resource-intensive. Salesforce teams often find themselves lacking the time and resources necessary to undertake such refactorings. This is primarily because Salesforce serves as a mission-critical system, and various departments consistently introduce new requirements.

Given these constraints, it becomes crucial to initially build processes with common sense and adhere to best practices. This approach helps mitigate the need for extensive refactoring efforts down the line.

As mentioned above, processes built on common sense principles will rely on robust data models and ensure the population of high-quality data. This data will be easy to report on, less prone to bugs, and readily understandable.

Every salesforce org has technical debt and every salesforce team produces some amount of technical debt unvoluntarily. Bad processes inherintly open doors for more bad processes because technically they're not scalable and have lots of dependencies to other processes or metadata. It's super easy to hit governor limits of salesforce when an org has lots of bad processes. Decoupling these processes and refactoring them often result in bugs and data integrity issues and requires a great amount of attention to detail and technical capabilities.

Flows are often advertised by Salesforce as an easy solution to attract more customers and make it simpler for Salesforce professionals to enter the market. They're simple to use—no coding or test classes needed. But they have downsides. For example, if a flow isn't specific enough, it can eat up a lot of CPU time with bulk updates. Also, if flows keep getting retriggered, it can hit limits and cause operational problems. And if you try to solve complex problems with flows, it can make the whole thing messy and hard to manage. So, if your first consultant relies too much on flows, it's a warning sign. They might be rushing things and leaving you with a mess to clean up later.

This aspect is often overlooked but it's crucial. Consultancies and freelancers not only set up your Salesforce system but also introduce a new language to your organization. We teach you standard Salesforce terms like leads, accounts, records, fields, and page layouts. Additionally, we establish naming conventions for new processes or for other metadata, such as queue names, Apex classes, and fields. Once everyone in the company learns this language, it's tough to change. In fact, I'd say it's even harder than technical refactoring.

In large-scale Salesforce projects, a major problem is the abundance of bugs due to poorly tested Apex code. This code often lacks clear test cases, meaning developers don't use Test Driven Development. Debugging in Apex is tough, and setting up test data is complicated, so developers often deliver code with insufficient test coverage (the minimum 75%) that doesn't adequately test the intended outcomes.

Generating test data for a data-driven platform is a big challenge, especially in agile projects where the data landscape changes rapidly. Even small changes can create complex scenarios, leading developers to focus on simplicity. But this can cause problems later when their code doesn't work properly in real situations. So, having realistic test data is crucial.

At first, developers might create methods to make common data like users or accounts, which works for simple setups. But as projects get bigger and run into issues with dependencies and data limits, developers need a consistent way to work together, save time, and create reliable test data to ensure they meet project goals, especially when using Test Driven Development.

It's crucial to have testing frameworks built-in from scratch because implementing them later on is really challenging, as all test classes need to be changed and thoroughly tested.

Apex trigger frameworks are vital in Salesforce development for organizing code efficiently, managing governor limits, and ensuring reliable trigger execution. These frameworks structure trigger logic into separate handler classes, simplifying maintenance and collaboration. They also optimize code to stay within platform limits and maintain data integrity by controlling trigger execution order.

Trigger frameworks enhance code robustness, testability, scalability, and maintainability. They include error handling and logging mechanisms for graceful exception handling and promote unit testing for individual trigger handlers. Overall, trigger frameworks empower developers to build high-quality, scalable, and maintainable trigger logic that meets business requirements while adhering to best practices.

When setting up a new org, people are a big part of the equation. However, consultants and freelancers often skip the step of figuring out who's who and what permissions they need. Instead, they just grant permissions as people ask, without thinking about roles or profiles.

So, what happens? Well, each person ends up with their own set of permissions, and when new folks join, they're matched to someone else's permissions. Over time, this leads to a mess of permission sets scattered across the org. Plus, people in similar roles can end up with totally different levels of access.

As the org grows, it becomes a headache to untangle who has what permissions and who should have what. To avoid this, it's crucial to start off with a plan, assigning permissions based on roles or personas rather than just handing them out willy-nilly. It'll save a ton of headaches down the line.

Once endpoints are created, changing them in the future becomes challenging because it involves not only a Salesforce change but also potential changes required by other systems making callouts to the endpoint. Most of the time, established endpoints remain unmodified due to these reasons. Therefore, it is crucial for consultancies and freelancers to create endpoints with scalability in mind and adhere to best practices.