Journey to Salesforce Certified Application & System Architect

Journey to Salesforce Certified Application & System Architect

Inside four years I have passed the 9 exams on the Salesforce Architect pyramid (including the two optional Admin and Experience Cloud exams), and now have both Salesforce Certified System Architect and Salesforce Certified Application Architect.

The following are some observations along the way:

  • Certifications give you much more than just badges. They will expose you to features and practices for your real work that you may not have otherwise seen or considered. Many problems in complex orgs are that either the designers not fully understanding the platform, or not sufficiently selling the benefits of lower customization to stakeholders.
  • It took me four years but speed was not my focus. It should be done at whatever pace works for you. You could do them all in 1 year, but then you are probably just doing it for the sake of badges and may not fully absorb the lessons learnt
  • Pandemic lockdown had a big impact on my learning. After working all day at home it was very hard to be motivated to study in the same location. I took just one Salesforce exam in 2021
  • Experience Cloud Consultant was optional, but still very useful. The subject matter also covered questions that would appear in many of the Architect level exams as well
  • Administrator was very hard because the questions could be about almost any setup feature. It can be useful to have, but if you are committed to the full Architect journey then you can probably skip it
  • Development Lifecycle Architect turned out to be an easy one. I’ve not had to be ‘hands on’ with any Salesforce deployment, however development and release planning means you really need to understand your sandboxes. Understanding sandbox refreshes, licenses and best practice is valuable.
  • Integration Architect was tough because it was full of multiple correct answers, and you have to choose the ‘most correct’ from the writers perspective. Did not enjoy.
  • Sharing and Visibility Architect was probably the most valuable learning I’ve had from all the certificates. Even if you’ve worked with complex orgs, there is probably some features of sharing that you have yet to discover.
  • Focus on Force was great for all exams on the CAA side of things. Recommend paying the reasonable price (USD $20 each) for the practice exams. The learning modules are also good although optional.
  • Check out https://scuvanov.github.io/SalesforceCertScoreCalculator/ after each exam to see how close you probably were. This is not exact, but if you need to plan your retake then it is good to know if you were a couple of questions out or maybe much more.

Additional notes on costs:

  • Three exams I received vouchers from local community groups. Others I was able to find a modest voucher online.
  • Salesforce run cert days —Salesforce Certification Days that give discounts on the USD $200 exams in exchange for attendance
  • ‘Architect’ level exams (USD $400) have far fewer applicable vouchers in circulation. Vouchers for the ‘standard’ (USD $200) exams often do not apply.
  • Reddit users often lists new voucher codes: Salesforce (reddit.com)
  • Paying $20 for Focus on Force practice tests can save you the $100 or $200 retake cost for the exam. I am satisfied with my purchase of all of them (and passed first time with their help)
  • The full price of Salesforce exams are actually pretty good value by IT industry standards. Employers will value the certs far higher than you paid for them.
Advertisement
Things to know about Permissions before starting Salesforce Functions

Things to know about Permissions before starting Salesforce Functions

Salesforce Functions are finally GA in Winter ’22, and offer the ability to add more powerful coding capability to your Org. There are however some restrictions with respect to API access and record sharing you should know about beforehand:

  1. One Permission Set to Rule Them All:

All functions have the same permissions to your Org, and the Functions Permission Set is the only one that defines access, so you can’t for example have a Function that can only read Opportunities and a Function that can only write Leads.

2. You can’t execute code as the invoking User or ‘WITHOUT SHARING’:

The code will execute as per the “Cloud Integration User” along with the assigned Functions Permission Set. That means the sharing settings of the invoking User will not be used, nor the ability to run the function without restrictions (using WITHOUT SHARING).

3. Configuring the Functions Permission Set is extremely limited by the “Cloud Integration User” license:

This license really restricts what permissions you can enable in your Functions Permission Set. For example ‘View All Files’ or allowing the Tooling API is not possible. As far as I can tell you are limited to read/write access settings on main objects for the most part, with anything that gives you elevated access to the Org being forbidden.

4. Permissions in the Local Docker environment are NOT the same as the Compute Environment:

The restrictions in the Functions Permission Set above do not apply at all to code that you deploy to Docker, which is great until you actually want to deploy it to your Compute environment and find the code can’t actually run.

Conclusion

It is great that Salesforce is allowing all developers to build Functions locally in Docker today, however it is problematic that many will produce all kinds of great functions and demo those to their stakeholders, only to discover too late that they will not work after deployment. I would recommend creating a test user with minimum access and assign them the Functions Permission Set, just to ensure that your SOQL queries and other API functions are not limited (run in the Developer Console or whatever).

Functions are very new however, and hopefully some of these restrictions will be addressed in future releases.

Salesforce Winter ’22 Highlights

Salesforce Winter ’22 Highlights

The Salesforce Winter ’22 release notes have been released. https://help.salesforce.com/s/articleView?id=release-notes.salesforce_release_notes.htm&type=5&release=234

As usual, I have scanned through and picked out items interesting to me. This release does feel particularly extensive, and the I could easily double the count of exciting features below:

New features

Improve Page Performance with More Custom Lightning Component AnalysisLINK

Being able to get additional web page analysis is helpful is you want to really optimize specific pages. You will get additional analysis of your CSS, Javascript and other aspects that could be optimized further.

Fast-Track Your Queries with SQL for Tableau CRM (Generally Available)LINK

This is interesting to those of us more familiar with SQL than SAQL. It isn’t 100% equivalent to ANSI SQL, but a useful addition regardless. It would be awesome to get this in Salesforce CRM as well! (I doubt that will happen)

Control Access to Sensitive Data with Restriction Rules (Generally Available)LINK

Secure your data and boost productivity by permitting your users to see only the records necessary for their job function. Create restriction rules to control which subset of records you allow specified groups of users to see. Restriction rules are available for custom objects, contracts, tasks, events, time sheets, and time sheet entries. This feature, now generally available, includes some changes since the last release. You can now create and manage restriction rules in Setup as well as with Tooling and Metadata APIs.

Control the Default Records Your Users See with Scoping Rules (Beta) – LINK

Reduce noise and unnecessary searches while enhancing your users’ productivity. Based on criteria that you select, you can set rules to help your users see only records that are relevant to them. By adding a scoping rule, you can help users focus on pertinent records and prevent them from accessing records containing sensitive or inessential information. Scoping rules don’t restrict the record access that your users already have. Your users can still open and report on all records that they have access to per your org’s sharing settings

Secure Your Components Better, Stronger, Faster with Lightning Web Security (Beta)LINK

Extra security for your LWC components, and a replacement for Lightning Locker

Expose Events in the Lightning App Builder LINK

Now Lightning Web Components can expose events for wiring together with other components in the Lightning App Builder.

View Dependencies for Lightning Web Components LINK

A dependency tree to see what APEX classes and other components your LWC controls rely on.

Unleash the Power of Elastic Compute with Salesforce Functions (Generally Available)LINK

Been waiting for this for a while, finally GA! Not sure if we can try this directly in Developer orgs in Winter ’22, or if it still needs to be enabled by an Account Executive.

Time input on lightning-input-fieldLINK

Minor feature – now specify time in 15 minute increments

Flow BuilderLINK

There are usually a lot of new Flow features every major release, but this release is wild – just take a look. This will require a dedicated article by itself.

New Tableau CRM wire adapters – lightning/analyticsWaveApi (Beta)LINK

Lots of new wire adapters to integrate Tableau CRM directly into your LWC components

Stuff to prepare for in the future:

As always, Salesforce have announced platform changes that you will need to start preparing for

Get Ready for the Future Requirement to Enable Multi-Factor Authentication (MFA)

Salesforce will contractually require MFA on all user logins from 1st February 2022. The release notes are not helpful however in describing what the impact of not complying with MFA by that date is. This can be problematic for high volume Experience sites – LINK

Legacy API Versions 21.0 Through 30.0 Are Being Retired

After the deprecation in Winter ‘22 of API’s 21 and below, Salesforce is now giving notice that Summer ‘22 will deprecate all API’s 30 and below. Summer ’23 release will deactivate these API’s for good – LINK

Salesforce LWC inheritance and code sharing

Github Project: https://github.com/andrewwhitten/Salesforce-LWC-Snippets

Salesforce Lightning Web Components (LWC) were only introduced recently in the Spring ’19 release in 2019, and have rapidly taken over from Aura as the default choice to create new User Interface components.

The ease of use and deployment is impressive, although every time you create a customization for your Salesforce org, whether it be an Apex trigger class, custom object or LWC component, you are also creating an artefact that will require maintenance for a long time.

Salesforce provide guidance on LWC composition, which is to say the best way to build components is to build them out of smaller components like Lego. They even say “Inheritance is allowed, but it isn’t recommended because composition is usually more effective“. This is good advice on the smaller side of things; if your org has a maximum of 30 LWC controls then over-engineering your LWC components isn’t going to be productive.

I can however think of scenarios where it is worth considering from an architectural point of view.

  1. One complex LWC component that has been broken up into smaller units by composition. Each child control may share exactly the same javascript functions, variables and CSS styling.
  2. A collection of child LWC components that work differently but all raise exactly the same notification event.
  3. A suite of 10 functionally independent LWC components that should share specific styling. A style change in one should reflect in the others.

I have created a purposefully simple project on GitHub that demonstrates how you can use inheritance for simplifying your child LWC components. The code is simple enough that you can see how the inheritance works and change it real time in your local development server:

Further Reading:

  1. Composition: https://developer.salesforce.com/docs/component-library/documentation/en/lwc/create_components_compose_intro
  2. Share Javascript code: https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.js_share_code
  3. Additional Javascript Files for Sharing Code: https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.create_components_javascript_share
  4. Inheritance in LWC (article by Dhanik Lal Sahni): https://salesforcecodex.com/salesforce/inheritance-in-lightning-web-component/

Salesforce Summer ’21 – Highlights

Salesforce Summer ’21 – Highlights

I’m finding that the Summer ’21 is going to be an interesting release mostly for the items that are still in Beta – the forthcoming improvements to Security control and investments in Contact Center enablement. This release actually doesn’t feature too many developer specific items, however the overall Salesforce platform is improving a great deal.

Full Release Notes here. I’ve listed out my own highlights below:

Pilots & Betas

These are available through your AE:

PilotSecure Apex Code with User Mode Database Operations – Finally Apex can run database operations in user rather than system mode.

BetaPermission Set Groups now with expiration dates –  End date your users’ permissions

BetaControl Access to Sensitive Data with Restriction Rules – This is one that is worth everyone at least understanding. Salesforce’s current sharing and visibility model gives automatic access to detail records if the user has access to the master record. This change should allow more configurable access to these. Hopefully the ‘Sharing & Visibility Designer’ exam will update when this goes GA

Beta – Contact Centers – Omni Channel Routing – Use new Flows to route to the most appropriate / qualified agents

Beta – Contact Centers – Streamline After Conversation Work – Dedicated time allocated (and monitored) to ensure that your Agents complete ACW (After Conversion Work)

Sharing

See Record Access Reasons in Lightning Experience – great to be able to use this from Lightning now – https://releasenotes.docs.salesforce.com/en-us/summer21/release-notes/rn_forcecom_sharing_view_record_access_lex.htm

Experience Cloud

Experience Cloud SharingGrant Unauthenticated Guest Users Access to Records Owned by High-Volume Users – more sharing capability, this time for high volume users sharing records to Guest users – great to be able to configure this rather than to create Apex sharing code

Experience Cloud Service Unavailable PageMaintain Business Continuity with the Customizable Service Not Available Page – Useful to have this page available in case your Experience Cloud site goes down – the previous experience was just confusing

Development

Quick ActionsCreate Quick Actions with Lightning Web Components – This quickly became GA. Create Quick Actions with LWC components in Record Pages that either run a headless Action (update something in the background) or open a window inside your current record page.

Lightning DevelopmentImprove Page Performance with Custom Lightning Component Analysis – The Page Performance analysis became a bit useful, breaking down each component down into performance. This will be useful when you are asked to optimize existing pages and are looking for a place to start.

Audit Trail Monitor Lightning Component Changes in the Setup Audit Trail – Now view when an Org’s Lightning components were added, changed or deleted.

Other

External ServicesApex Unit Testing With Flow And External Services – Now you can extend your unit tests to cover external service calls as well

FieldsInstall More Custom Fields – now the hard limit has increased to 900. You probably don’t want to take advantage of this, but it is there now. 

Einstein SearchEinstein Search (Generally Available) – I’m going to admit that I’m not completely clear what exactly has changed here based on the Summer ’21 Release Notes compared to previous versions, however it is obvious that you can now take full advantage of Einstein Search features no matter what edition of the (Lightning) platform you are using. Also specific inclusion of Knowledge in search results, with AI to help identify articles for your agents.

Data Quality Analysis in Salesforce files with MuleSoft Anypoint

Github Repository: https://github.com/andrewwhitten/template-sfdc-file-check

I have created a solution that can be added to any record page (Case, Account, whatever) and find the data quality / encryption / password protect status of all the attachments.

It comprises of aSalesforce LWC Lightning control and MuleSoft Anypoint 4.3 runtime service and you to extend the ContentVersion standard object, and drag and drop the control onto the page designer.

The interactions of my solution are detailed in the Sequence Diagram below. The data quality process is initiated by the Salesforce LWC control calling AnyPoint with a list of DocumentId’s to check:

The MuleSoft Anypoint 4.3 Flow will take a list of Document ID’s and start processing them. Currently it uses a For loop to check each file:

You don’t have to call this process from Salesforce – just call the service from a REST client or your browser: https://<YOUR HOSTING URL>/FileCheck?”GUID1″,”GUID2″,”GUID3″ :

What does this version detect?

  • PDF – Password protection
  • Microsoft Word (doc and docx) – Password protection
  • Zip file password encryption

What may future versions include?

  • Microsoft Excel password protection
  • Microsoft PowerPoint password protection
  • Image validation
  • Corrupt files

This proof of concept introduces a framework for working with Salesforce files in MuleSoft. You can analyze your files with any Java code you like. Do you need to scan all word documents for ‘Copyright of Acme’? Just write another Java class.

Disclaimer

  • Question: Is this Production ready?
  • Answer: No. This is currently at a ‘working proof of concept’ stage, but needs a lot more in terms of performance management, error handling and testing. You should only use this in your Salesforce developer sandboxes.

Problem Background

The Salesforce CRM platform does not yet have a coding capability to read and analyze large files. For example, if a user was to password protect a large PDF file would require a lot of inventive Apex coding from scratch to determine that it was password protected and unusable.

Java on the other hand can do this kind of file analysis, and take advantage of strong and capable open source libraries that are available to work for a variety of file formats. MuleSoft Anypoint is a popular integration product owned by Salesforce and used by many Salesforce orgs, that can further be extended with Java code.

There are other options, such as licensing Salesforce Heroku or maybe Serverless Functions when formally available. You can also create web services hosted on Microsoft Azure, AWS, or anything else. Many Salesforce customers have however invested in MuleSoft that does have strong Salesforce support out of the box. This design is not a compelling reason by itself to procure MuleSoft if you don’t have it already, however it is interesting if you already have MuleSoft and some spare capacity on it.

Notes:

  1. All this can be run on free trial services. Salesforce and MuleSoft have signup pages.
  2. You can run the MuleSoft AnyPoint service locally on your machine, however Salesforce won’t be able to connect to it (or at least you will have a hard job making the connection). You will need to deploy to AnyPoint Cloud with an SSL certificate for a full end-to-end.
  3. I’m running this on a medium AnyPoint vCore in the cloud (the highest available on the trial service). Performance seems fine, but there has been no real performance testing yet. There probably is a limit around how much you can throw at this service before it starts failing.
  4. You will need to add your MuleSoft service’s URL to CSP Trusted Sites in Salesforce Admin
  5. The web service is called from a LWC component directly. This can be secured to the calling host, but in the next version I would probably put into Apex so that it is called from the Salesforce org rather than directly from the browser.
  6. The ability to detect whether a document is password protected was actually not as easy as I had imagined. Open source libraries are great, but they really lack a simple isDocumentEncrypted() function.
    • PDF password detection comes courtesy of Apache PDF Box 
    • ZIP password detection is with the standard Java libraries.
    • Microsoft document password detection uses Apache POI
    • Other file types and other types of file quality detection can be added to the MuleSoft solution just by adding a new Java class and libraries
  7. The next step is to extend this to determine issues when users uploads a file through the UI. For example, rejecting an upload of an encrypted PDF
  8. I’m not so experienced with Anypoint, so my Flow is rather long. I’ll also look to break that up in anticipation of other services that will come and reuse common parts
  9. I should also create a ‘how to set up’ page with detailed instructions. Please ping me if that is of interest.
Salesforce Spring ’21 – Developer Highlights

Salesforce Spring ’21 – Developer Highlights

Salesforce Spring ’21 is nearly upon us, and these are my highlights for Developers from them. Obviously there is a lot more in the notes, so always encourage you to read through fully yourself.

Developers

  1. Track Changes between your local Project and a Sandbox

This hasn’t really been a big issue for me since I can rely on Git for determining changes in my metadata, however there may be scenarios where you want to make a lot of configuration changes and this will help you identify and track them better.

2. Create Scratch Orgs with More Features

Great to have more feature control. I just checked and it seems Person Account feature  (that I was looking for) has actually already been available for a while now!

3. SOQL – Select predefined groups of Fields ( SELECT * ) 

I’m not really sure about this one. The lazy SQL developer uses SELECT * and will usually cause issues down the track. Being able to use this in SOQL with SELECT FIELDS(ALL) is convenient, but I’m concerned that developers will just use that by default rather than consider which fields they truly need. This may or may not have performance implications, however it could easily have security implications where some PII data hasn’t been secured. On the other hand, if you need to select all the fields anyway then this will make for cleaner code.

4. Lightning – DOM API changes

Do you have automated tests for your org? (Selenium, Tosca, etc) Salesforce has been changing the way the HTML code is named, so you will probably want to check for breakages in your test suites ASAP.

5. Lightning – Customize lightning-map control

You now have greater control over the behavior of the map control such as disabling panning, buttons, etc, and can define your own map marker icons as well. This isn’t a huge leap, but great to see that Salesforce is still improving this control. There will always going to have the issue that it won’t be allowed to compete with MapAnything, but I find it a valuable control for limited scenarios.

6. Lightning UI components to be deprecated

This was announced a year ago for Spring ‘20, but now the time is almost upon us! As of May 1st 2021 all UI namespace components will no longer be updated or supported.

7. Salesforce Functions (beta)

This has been a long time coming. Formally known as EverGreen (I think, it was hard to keep track) there has always been some rather mixed messaging from Salesforce around this. Still, an interesting new beta feature that could provide you with alternatives to Apex, although not clear if additional licensing is required.

8. Apex Job Transaction Finalizer (beta)

Strange beta in that you can use this in Production from Spring ’21. Use a finalizer at the end of your Apex to handle or rerun failed jobs. I’ll need to spend some time on a POC to understand this one fully.

Creating a Salesforce Permission Set subset from multiple Profiles

This tool is for reducing the size of your Profiles by extracting common elements and placing in a common Permission Set.

Complex Salesforce orgs often have large Profiles, and Users can only have one Profile. This means that when you create a new App or implement a Release Update (for example), then your Admins will need to go through and ensure all Profiles are updated the same way. You will then also have to test each Profile fully.

I created a simple command line utility to identify the most common elements in a set of Salesforce Profiles and generate a common subset Permission Set as well as the newly reduced Profiles.

https://github.com/andrewwhitten/Salesforce-Profile-Refactor

Salesforce provides Permission Sets and Permission Set Groups that allow you to define a set of Permissions not tied to any Profile. This means for example that if you have 100 class accesses that are needed by multiple Profiles, you could define one Permission Set and assign to everyone who has those Profiles.

In a really simple example, I cloned three new Profiles from the standard ‘Minimum Access – Salesforce’ Profile. (In a real world example this hierarchy would be better defined as Roles). Each has Profile level access to different Apex Classes in our Org:

Initial Profile state

We can see that all these Profiles have access to the X-Wing and Y-Wing classes, so we can add those to a Permission Set:

Reduced Profiles with common Permission Set

Furthermore, we can see that the ‘General’ and ‘Major’ profiles have other common classes, meaning we can divide up further:

Reduced Profiles with two common Permission Sets

Now, the Rebel Alliance has just acquired a new B-Wing vehicle for everyone. To grant access the Admin can now just add this to the main Permission Set, instead of to each Profile:

Adding a new permission element that everyone has access to

For such a simple example it is easy for an Admin to set this up by hand, however what if you have 15 profiles that are thousands of configuration lines long?

The tool generates a Permission Set, however if your common files are still large then I would suggest looking at creating a Permission Set Group and splitting the generated Permission Sets up inside it instead.

Assumptions

This post will only cover the generation of Profile and Permission Set metadata files. The process for pulling and pushing Profile metadata from an org really depends on how well your devops is set up. SFDX tools can pull and deploy Profiles, but not consistently without some issues.

Warning and Disclaimer

Always use this tool in sandboxes and never directly in Production! Try and design an improved Permission Set and Profile combination in a sandbox, and then test that extensively. You need to have personal confidence that the new Permission Set is going to work for your users.

If you do progress to Production, then also do have a roll back strategy to the old Profiles.

Finally, please ensure that you have all the training and knowledge required to pass the ‘Sharing & Visibility Designer’ Certification. You really need to understand how Profiles and Permission Sets work, and all potential impacts to your org. Unit Tests, manual testing and automated testing are rarely comprehensive enough to catch every scenario.

Instructions

  1. Ensure Microsoft .Net 5.0 is installed on your system (Windows, Mac or Linux)
  2. Place all Profile metadata files in the \input directory (you can specify another directory for input and output if desired)
  3. Run this command (sample input files provided): dotnet SalesforceProfileRefactor.dll \input \output

MacOS Example:

Run the tool from the command line

You will see a new folder generated under ‘Output’ with the current date and time stamp. Inside is the common Permission Set as well as the newly reduced Profiles:

How the tool looks

Open the generated Report.csv in Excel (or similar), and you will see that it has moved 2 Apex Class access elements and 5 user Permission elements into the common Permission Set:

The output report in MS Excel

Changing the code:

The tool has been developed in Microsoft .Net 5.0 and should run on Windows, MacOS and Linux. You can change the code in community (free) versions of Microsoft Visual Studio 2019 for either Mac or Windows.

Notes:

  1. I chose to do this in C# .Net because I already knew how to manipulate XML with it. Additionally Visual Studio is great at generating the XML schema wrapper class.
  2. At this early stage I doubt there are many people who need this utility. Even I am hoping to use it very rarely. Java would have been a more natural choice for the Salesforce community, but would have taken me longer.
  3. Code Optimization – I traded accuracy and reliability over code speed. I have a recent i7 running at 2.8 Ghz and the whole operation takes less than 7 seconds to process 600,000 Profile configuration lines, therefore I am not too concerned about it.
  4. GUI – I have some thoughts about extending this with a user interface to help visualize the process better, perhaps by comparing specific types of elements and attributes between files rather than all.
  5. Naming – Ensure that the name of the files is correct for either Sfdx or older metadata deployments. I might include this as a command line option in future.

Experience on passing the Salesforce Certified Data Architecture and Management Designer

Experience on passing the Salesforce Certified Data Architecture and Management Designer

I had planned to take the Salesforce Certified Data Architecture and Management Designer exam at the beginning of 2020, but between a major change in the exam’s structure in March and challenges to both study and work from home since then I have delayed until now. After passing the exam this weekend I wrote down some thoughts:

This exam had a lot of multiple ‘Correct’ answers, requiring you to select the ‘best’ one. This made me uncomfortable, but my strategy was just to choose the answer I would use in real life and not try and second guess what the examiner was thinking.

Many questions were helped by my real life experience of large and complex orgs. In fact it would have been extremely hard to pass this exam by study alone. Some questions I had not studied for at all, and just knew from my own experience.

Maybe I’m now used to these exams, however I found the questions clearer and easier to parse than in my previous Salesforce exams. I didn’t even write down on the (supplied) paper pad anything to deconstruct them  this time..

Areas to consider:

  • The difficulty of the questions varied significantly, from really basic to really hard and nuanced. If you find yourself despairing then really just push on, you will get to easier ground soon enough. The pass mark is 59%, and I’m sure that you can get within striking distance by just answering the easy ones first.
  • Many question topics were also covered by the Salesforce Certified Sharing and Visibility Designer exam. Many people say that exam was harder, so I was well served by having completed that already. I would suggest putting in the study for that exam as well, even if you do not intend to take it yet.
  • Be across your Salesforce licensing and usage limits. Yes, Salesforce can do it, but does your org have the licensing to back it up?
  • Integration! When is it best to use Salesforce Connect, Data Loader, REST/SOAP API, or third party ETL tools? Think about scenarios where your users need to access data held in another system.
  • Some questions were not clear if the best solution was a Salesforce tool or a third party tool. It is a Salesforce exam, so obviously you are going to be tempted to go with the Salesforce option with all other things being equal. Not sure what to recommend other than go with what you think is right.
  • When to use a managed package from the AppExchange? This is challenging because many of these products charge by the amount of users, and if you have thousands of users then it is non-trivial to suggest your business procure a managed package in real life if it can be avoided. Salesforce does however recommend implementing custom code as a last option, so just bear that in mind.
  • The Focus On Force exam preps and practice exams were valuable and good value. I feel that although they won’t help you pass the exam by themselves, they will nevertheless bring you to a higher level after you finish the trailhead materials.

The worst thing about these exams (not specific to Salesforce) is that there is no way to go back and discuss what the right answer should have been for some of those borderline questions. It would be great if Salesforce allowed us to flag and give feedback on each question as we go through. The one text field at the end doesn’t really help for this (at this point you have committed and just want the results already!).

There you have it. Good luck on your exam and reaching Certified Application Architect!

Installing Visual Studio Code and Salesforce SFDX tools without being System Administrator

Installing Visual Studio Code and Salesforce SFDX tools without being System Administrator

I have a new shiny, high specification Windows 10 Laptop from my company. Naturally it is completely locked down from a security configuration.

I’m really fine with this. Developers should always work in least privilege and my company data should always be secured. Sure, it is easier to make progress with your Administrator override buttons, but the pain is just going to come back when you actually need to deploy something.

Microsoft gets this. Visual Studio code installs into my User Level profile without requiring any Admin privileges at all.

However, Salesforce doesn’t seem to get this. As far as I can tell there is no guidance around how to setup your development environment when using a locked down system.

However, you can install with least privilege, but takes a few manual steps which should take you no more than 10 minutes:

  1. Install Microsoft Visual Studio Code
  2. Install Salesforce Extensions for VS Code
  3. Setup Java JDK
  4. Setup NodeJS (with SFDX)
  5. Create a Windows Batch file on your desktop (or wherever):
    • Create VSCodeLocal.bat with a text editor such as Notepad (be careful – notepad will probably put a hidden “.txt” as the suffix)
    • Extend the PATH variable with the Java Bin and SFDX folders, and launch VSCode. See image below.
  6. Double click on VSCodeLocal.bat
    • I recommend running this from the command line first to ensure that no errors are experienced
    • Always run from this batch file. Directly running from the Visual Studio Code desktop/menu icon won’t work.

So at this point you should have a (mostly) working SFDX development environment on your locked down Windows 10. Do let me know in the comments if any steps require elaboration.

Notes:

  1. Try installing normally first. Your PC may not be as restricted as mine.
  2. Most SFDX commands work, such as ‘SFDX: Create Project’, SFDX: Authorize an Org’, ‘SFDX: Create Lightening Web Component’ and ‘SFDX: Deploy This Source to Org’. I haven’t tested everything.
  3. Installing the SFDX local development server doesn’t work for me because my company policy doesn’t allow scripts to be run. Your mileage may vary.
  4. 100% credit to https://www.vermanshul.com/2019/11/quick-tips-setup-sfdx-manually-without.html for the NodeJS/SFDX setup
  5. This process will probably generally work for a restricted MacOS as well. Ensure that you set up launching from the command line in VS Code: Shell Command: Install ‘code’ https://code.visualstudio.com/docs/setup/mac
  6. Versions of all these tools will change all the time. The JDK 11 will probably be fine for years to come, but everything else should be latest as possible.
  7. As far as I can tell, this configuration is likely not supported by Salesforce.