Tackling the Visual Studio Head-Spinning Challenges

Error deploying or retrieving source: The file or directory that you tried to deploy or retrieve isn't in a package directory that's specified in your sfdx-project.json file. Add this location to your "packageDirectories" value, or deploy or retrieve a different file or directory. For details about sfdx-project.json, see: https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_config.htm

Solution that Resolved the Issue for Me was mentioned in 1st point:

1. It appears that something within the project files became corrupted. I recommend obtaining a fresh clone of the entire folder by deleting the existing one. Please ensure you have a backup of any uncommitted files before proceeding.
2. For some individuals, a simple solution that worked was opening VS Code, going to File, selecting New Window, and then opening the folder path to resolve the issue.
3. A few individuals found success by downgrading their Salesforce CLI version, resolving the issue they were facing.

If you have successfully created a new branch in Bitbucket but are unable to see it when attempting to check it out from Visual Studio, even after waiting for a few minutes or refreshing the page, you can try the following solution. - git fetch

1. Ensure that you have properly synchronized your local repository with the remote repository in Bitbucket. You can do this by running a git fetch command in your command-line interface or using the relevant option in your Git GUI tool.

Note : git fetch to get all available branches

Salesforce - System.HttpResponse[Status=Moved Permanently, StatusCode=301]

As of May 6, 2023 (Summer '23-), The Mock Services included in our project have ceased to function. An error message was received indicating a "System.HttpResponse[Status=Moved Permanently, StatusCode=301]".

Note : My Domain URL Format Changes When You Enable Enhanced Domains

Fix :

1. Verify the Named Credentials URLs & Update the Base URLs with the latest changed URL

    Step : Navigate to Salesforce Classic and Get the Base URL and update 

Ex :  Old   -  https://<CompanyName>--dev.my.salesforce.com

        New  -  https://<CompanyName>--dev.sandbox.my.salesforce.com

2. Auth Providers - Verify the Salesforce Configuration URLs an update according to the latest Base URL, as mentioned above.

Salesforce Standard API vs Custom API

When it comes to integration requirements, it's always a significant question, and external teams often wonder why we should invest time in building a custom API when Salesforce already provides a standard API.

Here are the points that can be used to make a design decision based on the business requirement.

Standard API:

Pros:

• Readily available for immediate use without any additional setup time or effort required
• Maintenance-free
• Optimal performance can be expected as it's a built-in standard feature

Cons:

• Highly interdependent. If any changes are made to the schema, they must also be reflected in the external system, otherwise it will result in failure (e.g., modifying or removing a field's API name)
• The absence of error handling adversely impacts investigation and troubleshooting
• Native support for monitoring and alerting is absent, but custom logic can be added to the object trigger to provide this functionality if necessary
• "Retrieving nested child object data for a parent requires individual calls to each child object, rather than being able to retrieve it in a single call. As an example, this would apply to Account --> Case and Contact
• The system only follows the platform's sharing and security rules and does not permit the use of 'with' or 'without' sharing principles flexibly
• Modifying the response received from the standard API is not possible, even if we need it in a different format. In such cases, a Salesforce case must be raised, but there is no guarantee that the response will be changed according to custom requirements
• It is not feasible to implement any custom logic such as validations and mapping

Custom API:

Pros:

• Custom APIs offer a high degree of customization, effectively addressing all the limitations of the standard API mentioned above.
• There is not a significant variation in performance between custom and standard APIs

Cons:

• Building a custom API demands development efforts and subsequent ongoing maintenance in accordance with business requirements