В этой статье, из личного опыта, расскажу как подготовиться к сертификации на App Builder! Какие ресурсы стоит использовать, а какие не принесут никакого толку, и на чём стоит быть сосредоточенным во время подготовки и сдачи экзамен. Начнём !
1. Основные моменты
2. Ресурсы для подготовки
3. Темы к изучению
4. Business Logic & Process Automation
5. Data modeling & Managment
6. Security
7. Mobile
8. Заключение
Основные моменты 
Направление развития
Перед тем как начать готовиться к сертификации на App Builder, нужно знать, на что она направлена. Цель и направление, по которому необходимо развиваться - это создание и настройка приложения без КОДА. Найти способ решения задачи, используя только стандартные инструменты или те, что можно найти на AppExchange.
Всё гениальное просто
Стоит чётко понимать что для решения большинства задач найдётся больше одного решения. Поставьте себя на место заказчика, который хочет получить решение как можно быстрее, желательно попроще, ну и подешевле. Так сложилось, что у App Builder сертификации принцип такой же. Поэтому в процессе подготовки и выбора ответов на экзамене выбирайте простейшие решения.
Практика и теория
Естественно, практика это важный аспект в усвоении информации, и 80% из того что вы будете изучать потребуется пропустить через руки, память то ведь на кончиках пальцев 
. Но и теоретической информации, которую нужно запомнить, тоже будет немало 
.
Ресурсы для подготовки 
И так, переходим к источникам информации, которые будут использоваться при подготовке.
Trailhead
Первое, что приходит на ум, это Trailhead. Не могу сказать, что это эффективный способ при подготовке. Сам же начинал с Prepare for Your Salesforce Platform App Builder Credential . Пусть этот ресурс и содержит множество практического и теоретического материала, который собран для подготовки App Builder, но польза от него сомнительная ̶с̶у̶г̶у̶б̶о̶ ̶м̶о̶ё̶ ̶м̶н̶е̶н̶и̶е̶ . А если ещё начинать проходить super-badge какой-нибудь, то можно потерять пару тройку часов, разбираясь, что же от вас хотят, а не с самим решением задачи.
Mock Tests
Пробное тестирование - это не просто набор вопросов, похожих на те, что могут быть на экзамене. Это весьма хороший способ найти свои слабые места и сделать учебный план более индивидуальным. На его основе вы и будете практиковаться. Здесь стоит работать в таком порядке:
- Пройти тест, и сделать список тех мест, где вы не уверены или ошиблись.
- Проходя по списку “слабых мест”, повторить материал из документации.
- При всех следующих прохождениях тестов, при каждом неверном ответе - переходим в указанный в вопросе инструмент. И пробуйте воспроизвести каждый из сценариев(вариантов ответа), указанных в нём. В том числе и не рабочие, что бы появилось чётка уверенность в том, что можно, а что нет.
Таким образом, ваша практика будет происходить строго вокруг тех тем, в которых у вас есть пробелы в знаниях. Опять-таки, не забывайте что от вас всегда требуется самый простой в реализации способ решения проблемы.
Вот пара тестов, которые охватывают все темы сполна и содержат минимум ошибок.
На 142 вопроса
На 45 вопросов
П.С Они не всегда содержат верный ответ, но и это хорошо, вы должны быть на 100% уверены в своём собственном ответе, а не в том, что пишут в тесте.
Темы к изучению 
Большая часть вопросов будет связана с Business Logic & Process Automation , Data modeling and Managment и Security. Но это не значит, что стоит забывать о таких темах как:
- Social
- User Interface
- Reporting
- Mobile
- App Development
Что-бы не схлопотать 0% правильных ответов по теме, в которой был 1-2 вопроса. Пройдём по некоторым разделам 
.
Business Logic & Process Automation 
Думаю, вы уже знакомы с возможностями каждого из инструментов автоматизации (если нет, то вам сюда). Важно выстроить их в порядке возрастания сложности реализации.
Например: существует задача, которая может быть решена любым из этих инструментов:
- Formula field
- Workflow Rule
- Process Builder
- Apex Code
Нас интересует наиболее простой способ решения! Сразу отбросим Apex Code, остаётся выбрать между двух инструментов автоматизации и Formula Field. Проще всего будет использовать Formula Field, естественно.
Например: Заказчик хочет убедиться, что при сохранении записи поле Email будет заполнено, если человек выбрал способ для связи с ним через электронную почту ̶л̶о̶г̶и̶ч̶н̶о̶ !
Validation rule будет здесь наиболее подходящим вариантом, хотя помимо этого варианта будет предложено workflow rule и т.п. Иногда, вопрос поставлен так, что нужно всегда быть уверенным, что поле заполнено. Какое же здесь решение?! Не дайте игре слов в вопросах вас запутать !
Execution context знать вам понадобится в тех случаях, когда вопрос будет касаться возможного результата. Зная, что за чем выполняется и как один процесс игнорирует другой, - вы с лёгкостью ответите на вопросы.
Например: Что будет, eсли Workflow rule записывает в поле значение, которое не должно пропустить Validation rule.
Подводя итог касательно подготовки и вопросов о PROCESS AUTOMATION. Для успешного прохождения этого раздела на экзамене нужно:
- Разбираться в сфере применения определённого инструмента
- Отработать кэйсы, представленные в тестовом экзамене; многие будет невозможно воспроизвести, что даст вам возможность сразу исключить вариант их списка возможных ответов
- Научиться видеть простейшее решение
Data modeling & Managment 
Если вам уже доводилось проходить сертификацию на Dev 1 и Administrator, то некоторые вопросы будут вам очень знакомы. Всё те же старые-добрые вопросы про разницу между типами связей и их конвертацию.
Schema builder
Особых трудностей с Schema builder быть не должно. Знание всех возможных действий, которые можно произвести с объектами, находясь на Schema Builder странице, какую информацию можно увидеть и какие элементы объекта можно менять или добавлять. 
Field Types
Знать, что происходит при конвертации одного типа в другой будет хорошим плюсом, так как вопросы будут связаны с возможной потерей данных. Одной документацией я бы не обходился. Советую посоздавать поля разной длины, забить их данными и потом попытаться конвертировать или изменять длину. Этого вам вполне хватит, чтобы предсказать возможную потерю данных при конвертации.
Data Import
Как избежать дубликатов при импорте данных, ограничения инструментов, которые можно использовать для импорта. Избавиться от дубликатов можно до, вовремя и после импорта. Тут вас и будут пытаться подловить.
Security 
Особое внимание я бы уделил этому разделу. В одном случае, группы пользователей должны иметь определённый спектр возможностей. В другом, из уже существующих групп нужно выделить одного или несколько юзеров. Иногда, это решается с помощью 1 из функций для ограничения или расширения возможностей юзера видеть или редактировать записи/некоторые поля. Сложнее становиться тогда, когда нужно объединять эти функции между собой, для получения необходимого результата.
Доступ к записям
Так как, существует несколько вариантов настройки доступа к записям, как на глобальном уровне так и на персональном, необходимо понять наиболее частые случаи, когда и какой подход будет наиболее удобен.
OWD
Если речь идёт о глобальном доступе или его ограничении к записям конкретного типа, то стоит сразу обратить внимание на OWD, а после уже на Profile или Permission Set.
Например: всем пользователям должны быть видны записи кастомного объекта, но только одна группа людей должна иметь возможность их менять. В каждом профиле выставить Read и только в одном выставить разрешение на CRUD операции? Можно представить сколько действий придётся сделать 
.
Решение сильно упрощается и сводиться к 2-ум действиям, если:
- Выставить в OWD : Public/Read-Only
- В необходимом Profile выставить Edit
В итоге напрашивается вывод, что в такой ситуации проще расширить доступ для всех, и сузить для одной группы людей, чем наоборот.
Sharing rules
Попадая в ситуации когда все пользователи уже поделены на группы и все роли разданы, но вдруг нужно выдать конкретному человеку(группе людей) доступ к записям, приходится прибегать к более узкоспециализированным инструментам. С ними проблем возникнуть не должно, документация на Sharing Rules и немного практики, взятой из тестов, дадут ясное представление случаев, где и как их лучше применять.
Связка Profile, Record Type, Page Layout
Частый случай, когда нужно выдать разное представление записи, которое бы состояло из определённого набора полей, разных значений Picklist и с разным доступом к редактированию и т.п. Функционал каждого из элементов удобен по своему. Иногда нужно уметь определить, где необходимы все 3 сразу, а в некоторых случаях проблему можно решить используя лишь 1. Будьте готовы варьировать их между собой 
Hierarchy
Включённая Grant Access Using Hierarchies из Organization-Wide Defaults или её отсутствие, может закрасться посреди вопроса. И в некоторых случаях, от вас может требоваться запретить вышестоящей роли доступ к записям нижестоящих при отключенном Grant Access Using Hierarchies на объекте. Не попадитесь на эту удочку 
Mobile 
Вроде бы ничего сложного, но для Salesforce1 редко что приходилось делать. Отсюда и проблема: понадобится немного с ним поработать, чтобы знать о возможностях этого приложения.
В этом разделе обратите внимание на такие вопросы.
Actions
Какой Action type может использоваться в мобильном приложении, какие у него ограничения и возможности ? Где он может быть размещён ?
Salesforce1 customization
Какие элементы могут быть изменены? К каким вы не имеете доступ для изменения ?
Так же почитайте про работу c Mobile layout.
Заключение 
В целом, думаю, становиться понятно что подготовка будет происходить с помощью тестовых экзаменов(mock tests). 20% информации понадобиться запомнить, остальные 80% будут состоять из поиска решений для разного случаев 
. Не пытайтесь придумать что-то сложное и будьте внимательны к мелочам. Удачи )