Podcast : Requirements evaluation & solution fit with Doug Ayers

In this episode I will be speaking with Doug Ayers (@DouglasCAyers) about his approach to interpreting requirements and evaluating the options to architect a solution.

As an experienced web application developer coming to the Salesforce platform more than 5 years ago, Doug already had extensive technical skills which he could to use to grasp Apex and Visualforce, but how did he adapt to working on a platform?  I asked Doug about his own experiences and the lessons which he now teaches to fellow developers.  We discuss the value of asking more questions to uncover the depths of requirements and how the significance of considering the way a  solution will be maintained over its lifetime is as important as how easily it can be created.

Doug’s a problem solver, as can be seen from his GitHub repository which hosts multiple utilities he has created to fill gaps in Salesforce functionality.  For example when Doug saw a question on Twitter asking how to migrate Salesforce notes & attachments data into the new Notes feature, he did some research and found that the feature wasn’t available out of the box.  So he wrote it himself!  He did the same for migrating file attachments to Chatter files, he created an automation Bot for Chatter groups, enhanced Campaign member management, the list goes on.   You can read for yourself on Doug’s blog at douglascayers.com.

You can find Doug on Twitter @DouglasCAyers.

Please leave feedback on the blog at TechnologyFlows.com or tweet me directly, I am @matmorris

Recorded in June 2017

This podcast interview was first published by Technologyflows.com

© TechnologyFlows

Subscribe Podcast Feed

Podcast : Processing Large Data Volumes using PK Chunking & Hyperbatch with Daniel Peter

In this episode I will be speaking with Daniel Peter (@danieljpeter) about processing large volumes of data on Salesforce.

Daniel is Lead Application Developer at Kenandy, an ISV who had built an ERP solution on the Salesforce Platform.

Daniel’s first hand experience of how the Salesforce multi-tenant database behaves has lead him to develop techniques for processing tens of millions of records.

He will describe the techniques which he has refined to ensure SOQL queries are executed with consistent reliability and not fall foul of the most common exceptions relating to row selection, which are:

  • Non-selective query
  • Too many query rows returned
  • Query time out during execution

Daniel will explain how the Batch Apex query locator can be used to implement a technique called PK chunking which allows fine-grained control of the number of rows to be processed in each batch which largely overcomes the 3 common exceptions.

Daniel has even gone as far as experimenting with parallel execution through his Hyperbatch open source project which you can download from GitHub.   An explanation and demo can be seen on YouTube.

Whether your Salesforce database contains tens of thousands or rows or or if you’re up into the 10 of millions Daniel’s tips on working with multi-tenancy are a real eye opener as to what is possible when you design for scale from the outset.

Please enjoy!

Please leave feedback on the blog at TechnologyFlows.com or tweet me directly, I am @matmorris

Recorded in June 2017

This podcast interview was first published by Technologyflows.com

© TechnologyFlows

Subscribe Podcast Feed

Podcast : Serverless Architecture with Francis Pindar

In this series of interviews I will be speaking with people on the frontline of Salesforce architecture & development.

In this first episode of the Architect Series my guest is Francis Pindar which is very fitting as he was one of the pioneers of the UK Salesforce Community scene and one of the first people that I came into contact with when I got involved with Salesforce back in 2010.
Since then he’s continues to be a source of ideas and wisdom to me and countless others.

Francis is:

  • 5x Salesforce MVP (2012 – Present)
  • Salesforce Certified Sales Consultant, Service Consultant, Developer, Administrator & Advanced Administrator.
  • AWS Certified Architect – Associate
  • TOGAF9 Certified Enterprise Architect
  • BCS Certified Enterprise Architect

Francis has worked in internet technologies for 20 years, the last 10 of which have been on the Salesforce Platform.
He is a specialist in the areas of Enterprise Architecture Design, Business Process Improvement, Project Leadership, Business Analysis & Migration strategies.

Follow Francis:

Please leave feedback on the blog at TechnologyFlows.com or tweet me directly, I am @matmorris

Recorded in June 2017
This podcast interview was first published by Technologyflows.com
© TechnologyFlows

Subscribe Podcast Feed

I failed my first CTA Review Board, here are the lessons that I learnt

On the 8th May 2017 I attended the Salesforce Certified Technical Architect Review Board examination at Salesforce Tower in London.  It lived up to it’s fearsome reputation and was an educational experience in itself.

The Result

I had been preparing myself for all possible outcomes since walking out of the final session of the exam with my head spinning and questioning whether I was even fit to tie my own shoelaces.  Talking with CTAs I met in the weeks that followed confirmed that many people feel the same way, so I had no clue as to what my result would be.  So I just had to wait.

Three weeks later the early morning email from certification@salesforce.com arrived.  There was a brief moment of excitement as I waited for the message to load.  Then “We regret to inform you…unsuccessful, Result: FAIL“.

I was disappointed of course, and then all the other emotions took their turn as I read through the detailed feedback included in the email.  I made notes as I went, thinking back to questions the judges had asked me, assumptions and choices which I’d made in my design.  I kicked myself for the easy things which I’d omitted from my presentation and got confirmation that I’d made a couple of fundamental mistakes with respect to security and large data volumes which sealed my fate.

It wasn’t a total disaster, there was positive feedback:

  • Good identification of on / off platform components and relationships
  • Logical presentation of requirements – easy to follow
  • Data model – identified most of the standard objects to use
  • Correct programmatic features vs declarative
  • Good sandbox discussion / integration
  • Good variety of best practices and strategies
  • Diagrams fair – a bit compact especially landscape diagram
  • Good engagement / presentation style

This confirmed that my preparation had been worth the effort but that I had not mastered all the knowledge areas.

Examination Day

Everyone I met did their best to make me comfortable and ensure that I had all the things that I needed during the 5 or so hours that the review process takes.  But it wasn’t possible for me to be relaxed of course.

I stuck to my plan for the 2 hours given to read the scenario and prepare the solution.  I found it challenging to extract every requirement from the 6 dense pages, but went line by line piecing together my ideas on A4 note paper as I went.  With 30 minutes remaining I transferred my draft sketches to the large flip-chart pages with markers.  There were still some gaps in my thinking (bad sign, see lessons below) but I was running out of time.  So I added some final details and validated my choices as best as I could.  Time up and I had 15 minutes to refresh and collect my thoughts for the presentation while the judges took a first look at the pages as they were taped to the presentation room wall.

This is the list of flip chart pages that I prepared:

  • Architecture Landscape Diagram
  • List of internal & external actors (users) & licenses needed
  • Data model diagram
  • Role hierarchy diagram
  • Deployment & testing pipeline, inc. sandbox types
  • Project governance structure
  • List of assumptions

For the presentation stage I treated the introduction as I would for real clients.  I started with a welcome and stated the purpose.  I went on to summarise the pain points that Company X had and the business objectives they were looking to meet using the new Salesforce solution.   I then moved to use the diagrams and introduce the systems, the actors and the key aspects of Salesforce which would be implemented (I was not comprehensive, see lessons below).  I was then ready to detail the solution and my recommendations.  I went line by line from the scenario and for each requirement described the Salesforce features or customisations which would be used, I made use of the diagrams as to illustrate to the judges the relevant details .  With time running short I was going faster and faster in order to cover the full list of requirements.  Time up, and a short break for me while the judges compared notes and prepared their questions.

I was then invited  back into the presentation room for the 40 minute Q&A section.  I enjoy debating solution options with clients and colleagues in the real world, but here the judges are permitted to only ask questions so that the candidate is restricted to their own knowledge and experience.  The majority of questions I was comfortable with but I also had a few instances of “erms…” and missteps where I got half way through my answer and then revised it.  It’s clear to me now that these were my weak knowledge areas and, true to form, the judges sniffed them out.

What I learned

After reviewing the feedback I have identified the knowledge areas that I need to strengthen.  Under pressure in the exam I didn’t have immediate recall of some features that were important to my solution because I had not practiced them enough in real-life or during revision.  For example, I didn’t remember that a registration handler Apex class is needed to set up users signing on via Facebook.  I will use more hands on study to reinforce my knowledge in the areas identified.

I have also reviewed the way that I approached preparing and delivering the presentation for the judges.  Whilst my first attempt followed the plan that I had, the experience has given me 3 key lessons which I think will help me in the future.

Lesson 1 : Add details to the diagrams as they are identified

I feel that this was my biggest preparation shortcoming.  There is only enough time to go through the scenario pages one time, so when a requirement is identified it’s vital to know how it needs to be detailed in the solution.  Synthesising requirements from the scenario onto the solution diagrams needs to be automatic and I made the mistake of trying to hold several requirements in my head in order to consider different options.  Whilst this may work during a day long workshop it’s no use in a 2 hour preparation stage of the exam.  In my situation I didn’t build up the role hierarchy and data model diagram as I went and this resulted in a lack of detail in my own understanding and consequently in the level of detail that I presented.

Lesson 2 : Diagrams need to be detailed and clear

A CTA colleague who is mentoring me uses the term “CIO ready” as the objective for the review board diagrams.  The data model and role hierarchy are crucial elements in any solution and I didn’t devote enough time to these diagrams to include all the details needed to help me explain my solution to the judges.  In part, the lack of clarity was a consequence of my failure to build up the diagrams as I went (lesson 1).

Here is my current list of the details that I ideally want to include on the major diagrams:

Data model

  • Standard objects should include their name & any alias from the scenario
  • Colour code standard and custom objects
  • Label each object with its organisation wide default sharing setting (public read-write, public read-only, private)
  • Label each object with the record owner(s) role as used in the role hierarchy
  • Indicate use of external identifier field if required for integration
  • Label object with estimated data volume
  • Highlight objects with large data volume (LDV) requirements
  • Include all relationships between objects (even if not directly relevant to solution)
  • Label relationship types between objects (master-detail, lookup)

Role hierarchy

  • Colour code internal & external roles (Partner & Community Plus license types)


  • Create diagram representing “to-be” architectural state
  • Include “as-is” systems to be retired (mark with a big X)
  • Colour code systems by location (Salesforce, 3rd Party, on-premise)
  • Label system integrations with their type (fire-forget, pub-sub, sync, async)
  • Label system integrations with security needs (2-way SSL)
  • Label SSO connections with their type (SAML, OAUTH, DA)


  • Draw sequence of all environments needed to develop, test and operate the solution
  • Label each environment with the Salesforce sandbox type to be used
  • Label each environment with types of tests to be performed (integration, regression, functional, end-to-end, user acceptance, …)
  • Include additional systems required to manage deployments (source control, continuous integration)

Lesson 3 : Fully describe each part of the solution

I have two examples from my own feedback which taught me this lesson.

  • When describing how SAML would be used for single sign-on by internal users I didn’t include details of my recommendation for the user provisioning and de-provisioning process.  I should have detailed this on my diagram to remind me (lesson 2)
  • When presenting my data model diagram I skipped over stating the organisation wide defaults and record owners for the objects.  I wasn’t clear and my diagrams were not clear (lessons 1 & 2) so I didn’t communicate crucial information

Some requirements in the scenario tested that I understood the dependancies between the feature needed for an explicitly stated requirement (e.g., SSO) and supporting requirements which are implicit when using the feature (e.g., user provisioning process).

The CTA study guide also sets out the judging criteria relating to SSO requirements as; “…design and justify an end-to-end identity management solution.” a reminder that requirements and solutions don’t exist in isolation from other parts of the scenario.  I plan to review the study guide again and check that my breadth of knowledge as well as my plans for diagrams and structure of the presentation to help me hit all of the objectives in each area.

The Future

I will be going back to the Review Board soon.  First I need to be confident that I have strengthened my knowledge areas and practiced some more mock scenarios to test my performance under pressure.

The standards of the CTA qualification are high and it really is a breed apart from the other Salesforce certifications.  My experience in studying the SalesforceU architect track and sitting the Review Board for the first time is that my knowledge of how  to design and describe the architecture of Salesforce based solutions has increased more than I would have thought possible.

I have a little more work to do, but I keep in mind the words of a long time CTA colleague; “Stay the course my friend!”.