Back

enterprise software course

Business Platform Developer Track: Customising a CRM with Code and Low-Code

Extend a cloud CRM with formulas, flows, code, interfaces and tests, safely.

about this course

What you will be able to do

L1 to L7 ladder27:00 h of lessons plus practice and sharingSelf-paced with peer circle
  • Remember Remember : data model and objects.
  • Understand Understand : formulas and validation.
  • Apply Apply : flows and automation.
  • Analyse Analyse : code basics: triggers and classes.
  • Evaluate Evaluate : interfaces and components.
  • Create Create : integration and apis.
  • Create Create : testing, release and quality.
  • Create Create : capstone: build, review and teach a small solution.

Task, condition and standard

Task

Extend a cloud CRM with formulas, flows, code, interfaces and tests, safely. Finish all 8 modules on a practice set-up.

Condition

A free trial or practice account, practice data only (never real customer data), a peer circle and a mentor for the final review.

Standard

Every module standard is met; records are kept; a peer and a mentor rate the work 'Meets' or better on the rubric.

Who it is for: Junior developers, admins moving into development, technical analysts. Requirements: a computer and internet. Materials: slides with notes, worked examples, activities, quiz, rubric.

How the ladder works: modules climb from L1 (remember) to L7 (create); the ladder section shows each level as a slide. Take them in order; the first three suit new learners, 4 and 5 suit practitioners, 6 and 7 suit advanced staff.

lesson by lesson

8 modules with worked examples

Module 1 Data model and objects 2 hRememberL1 Basic

Everything starts with the data model.

  • Objects, fields, relationships.
  • Field types and rules.
  • Naming standards.
Worked example. A custom object links to account with a lookup.

Activity. Design three objects for a service business.

Standard to meet. Name items following the standard and draw the relations.

Slides with notes

  1. Slide 1: Data model and objects: the idea. Speaker note: Say the idea in one sentence, then show it on screen. Objects, fields, relationships.
  2. Slide 2: Data model and objects: your turn. Speaker note: Let the learner do this activity: Design three objects for a service business. Check it against this standard before moving on: Name items following the standard and draw the relations.
Module 2 Formulas and validation 2 hUnderstandL2 Awareness

Rules without code.

  • Formula fields.
  • Validation rules.
  • Default values.
Worked example. A rule stops close date in the past.

Activity. Write five formulas and rules.

Standard to meet. Test all with good and bad data.

Slides with notes

  1. Slide 1: Formulas and validation: the idea. Speaker note: Say the idea in one sentence, then show it on screen. Formula fields.
  2. Slide 2: Formulas and validation: your turn. Speaker note: Let the learner do this activity: Write five formulas and rules. Check it against this standard before moving on: Test all with good and bad data.
Module 3 Flows and automation 3 hApplyL3 Foundation

Low-code before code.

  • Record-triggered flows.
  • Screen flows.
  • Scheduled flows and error paths.
Worked example. A flow creates a follow-up task when a case is closed.

Activity. Build two flows with fault paths.

Standard to meet. Check that the fault path sends a clear message.

Slides with notes

  1. Slide 1: Flows and automation: the idea. Speaker note: Say the idea in one sentence, then show it on screen. Record-triggered flows.
  2. Slide 2: Flows and automation: your turn. Speaker note: Let the learner do this activity: Build two flows with fault paths. Check it against this standard before moving on: Check that the fault path sends a clear message.
Module 4 Code basics: triggers and classes 3 hAnalyseL4 Practitioner

Code when low-code is not enough.

  • Trigger per object, logic in classes.
  • Bulk-safe code.
  • Limits and governors.
Worked example. A trigger handles 200 records at once without error.

Activity. Write one trigger and class.

Standard to meet. Process 200 records with no query in a loop.

Slides with notes

  1. Slide 1: Code basics: triggers and classes: the idea. Speaker note: Say the idea in one sentence, then show it on screen. Trigger per object, logic in classes.
  2. Slide 2: Code basics: triggers and classes: your turn. Speaker note: Let the learner do this activity: Write one trigger and class. Check it against this standard before moving on: Process 200 records with no query in a loop.
Module 5 Interfaces and components 4 hEvaluateL5 Specialist

Screens users enjoy.

  • Page layouts and components.
  • Reusable parts.
  • Accessibility.
Worked example. A single component shows the account health card.

Activity. Build one component.

Standard to meet. Check that it works on mobile and passes the access check.

Slides with notes

  1. Slide 1: Interfaces and components: the idea. Speaker note: Say the idea in one sentence, then show it on screen. Page layouts and components.
  2. Slide 2: Interfaces and components: your turn. Speaker note: Let the learner do this activity: Build one component. Check it against this standard before moving on: Check that it works on mobile and passes the access check.
Module 6 Integration and APIs 4 hCreateL6 Advanced

Systems talk through APIs.

  • REST calls in and out.
  • Authentication, named credentials.
  • Retry and logging.
Worked example. An order system posts to the CRM and retries on failure.

Activity. Design an integration with failure plan.

Standard to meet. Keep secrets out of code.

Slides with notes

  1. Slide 1: Integration and APIs: the idea. Speaker note: Say the idea in one sentence, then show it on screen. REST calls in and out.
  2. Slide 2: Integration and APIs: your turn. Speaker note: Let the learner do this activity: Design an integration with failure plan. Check it against this standard before moving on: Keep secrets out of code.
Module 7 Testing, release and quality 4 hCreateL7 Super expert

Ship with proof.

  • Unit tests and coverage.
  • Sandbox to live release path.
  • Peer review and rollback.
Worked example. A release goes live with 90% coverage and a rollback note.

Activity. Write tests and a release note.

Standard to meet. Run the tests until they pass and write the rollback.

Slides with notes

  1. Slide 1: Testing, release and quality: the idea. Speaker note: Say the idea in one sentence, then show it on screen. Unit tests and coverage.
  2. Slide 2: Testing, release and quality: your turn. Speaker note: Let the learner do this activity: Write tests and a release note. Check it against this standard before moving on: Run the tests until they pass and write the rollback.
Module 8 Capstone: build, review and teach a small solution 5 hCreateL7 Super expert

Now you put everything together and help others learn it.

  • Plan a small solution: data model, rules, a flow, one class and one screen.
  • Run a peer code review using a short checklist.
  • Write a one-page guide so a new developer can maintain your work.
  • Teach one part of it in a ten-minute session.
Worked example. A learner builds a case-tracking app, a peer finds a query inside a loop, the learner fixes it, and a new colleague then extends the app using the guide alone.

Activity. Build a small solution for a service business, review a peer's work, and teach one part of it.

Standard to meet. Show that the solution works, passes tests and has a guide, and that a peer can extend it without help.

Slides with notes

  1. Slide 1: Capstone: build, review and teach a small solution: the idea. Speaker note: Now you put everything together and help others learn it.
  2. Slide 2: Capstone: build, review and teach a small solution: your turn. Speaker note: Build a small solution for a service business, review a peer's work, and teach one part of it.

assessment

How you are checked

Evidence: your records from each activity. A peer and a mentor mark it. Pass: no criterion at 'Not yet'.

Marking rubric (Not yet, Meets, Exceeds)
CriterionNot yetMeetsExceeds
AccuracySteps wrongSteps right on practice dataRight and explained to a peer
EvidenceNo recordsRecords for each moduleRecords and a lessons note
Safety and privacyReal data usedPractice data onlyRules written for others
StandardMisses the standardMeets every module standardMeets and improves it

Ten-question check, with model answers

Q1. A custom object called Job must belong to an Account. Which relationship would you use and why?

Model answer: A lookup or master-detail relationship from Job to Account. Master-detail fits if a job should never exist without its account and should be deleted with it; a lookup is looser. (Covered in module 1: Data model and objects. To pass that module: Name items following the standard and draw the relations.)

Q2. Write the idea of a validation rule that stops a close date in the past. When does it fire?

Model answer: It checks that close date is not earlier than today and shows an error message. It fires when a user tries to save the record, so bad data never gets stored. (Covered in module 2: Formulas and validation. To pass that module: Test all with good and bad data.)

Q3. Why are formulas and validation rules tried before code?

Model answer: They are easier to build, easier to read for admins, and need no tests or deployment effort. Code is used only when they cannot do the job. (Covered in module 2: Formulas and validation. To pass that module: Test all with good and bad data.)

Q4. A record-triggered flow sends an email but the email address is blank. What should you have built?

Model answer: A fault path that catches the error and sends a clear message to an admin or logs it. Without it the flow fails silently or shows users a confusing error. (Covered in module 3: Flows and automation. To pass that module: Check that the fault path sends a clear message.)

Q5. A trigger runs a query inside a loop over 200 records. What is the problem and the fix?

Model answer: It makes 200 queries and will hit the platform limit on queries. Collect the IDs first, run one query outside the loop, and use a map to look up results. (Covered in module 4: Code basics: triggers and classes. To pass that module: Process 200 records with no query in a loop.)

Q6. Why keep logic in a class and only a thin trigger on each object?

Model answer: The class can be tested and reused, and one trigger per object avoids unclear run order. The trigger just passes records to the class. (Covered in module 4: Code basics: triggers and classes. To pass that module: Process 200 records with no query in a loop.)

Q7. Name two things that make a screen component accessible.

Model answer: Clear labels and good colour contrast, and use by keyboard alone. Also useful: text alternatives for images and a sensible reading order. (Covered in module 5: Interfaces and components. To pass that module: Check that it works on mobile and passes the access check.)

Q8. An outside order system calls your CRM and sometimes times out. How do you design for it?

Model answer: Use a retry with waiting time between tries, log every failure, and make the call safe to repeat so an order is not created twice. Keep credentials in a secure store, not in code. (Covered in module 6: Integration and APIs. To pass that module: Keep secrets out of code.)

Q9. A release has 70% test coverage and the platform needs 75%. What do you do and what else goes in the release note?

Model answer: Write more meaningful tests until coverage passes, rather than skipping the rule. The note should also list the changes and a rollback step. (Covered in module 7: Testing, release and quality. To pass that module: Run the tests until they pass and write the rollback.)

Q10. In your capstone, a peer review finds a hard-coded secret in a class. What is the action and why?

Model answer: Move it to a secure credential store and change the secret, because anyone who can read the code can see it. Then add the check to the review list. (Covered in module 8: Capstone: build, review and teach a small solution. To pass that module: Show that the solution works, passes tests and has a guide, and that a peer can extend it without help.)

levels L1 to L7

The ladder, slide by slide

Seven slides, one per level. Open each for the slide text and the speaker notes.

Slide 1 L1 Basic: L1 Basic: Know the words

Remember the basic terms: object, field, record, relationship and flow. Name what each one is for in simple words.

Speaker notes. Say each term once and show it on screen. Check the learner can point to a field and a record. Common mistake: mixing up an object with a record.

Slide 2 L2 Awareness: L2 Awareness: See the big picture

Understand how data, rules, automation and screens fit together in a CRM. Explain why low-code is tried before code.

Speaker notes. Draw one picture of the layers. Ask the learner to explain it back in their own words. Common mistake: thinking code is always better.

Slide 3 L3 Foundation: L3 Foundation: Build simple things

Apply what you know to build objects, fields, formulas and a simple validation rule. Test them with good and bad data.

Speaker notes. Give a small case and watch them build it. Check names follow the standard. Common mistake: testing only with good data.

Slide 4 L4 Practitioner: L4 Practitioner: Automate and code safely

Apply flows with fault paths and write a bulk-safe trigger with a class. Analyse a failing flow and find the cause.

Speaker notes. Provide a broken flow and a trigger with a query in a loop. Check they fix both. Common mistake: ignoring limits until the live system fails.

Slide 5 L5 Specialist: L5 Specialist: Connect and test

Analyse an integration and evaluate its failure plan. Write tests that prove the work and prepare a release with rollback.

Speaker notes. Ask for the retry and logging plan before the code. Check coverage and rollback note. Common mistake: secrets saved in code.

Slide 6 L6 Advanced: L6 Advanced: Design and review

Evaluate other people's designs and code against a checklist. Create a design that balances low-code, code and cost.

Speaker notes. Run a peer review with the checklist. Check feedback is specific and kind. Common mistake: reviewing style only and missing risk.

Slide 7 L7 Super expert: L7 Super expert: Lead and teach

Create a whole solution, set the standards for a team and teach others to follow them. Evaluate trade-offs across the full platform.

Speaker notes. Ask the learner to teach one topic and review a team's design. Check the guide lets a newcomer continue alone. Common mistake: keeping knowledge in one head.

jobs this leads to

Where this takes you

  • CRM developer. Builds custom logic and screens.
  • Integration developer. Connects the CRM to other systems.
  • Test analyst. Writes and runs tests.
  • Technical lead. Reviews design and releases.
  • Platform architect. Designs the whole solution.

Next courses: data skills, process improvement, a sector course for your target employer.

ten locations and global

Your place

Local law changes how you store customer data and issue invoices. Check it for your place first.

India (Bengaluru)

Language: English, Hindi, Kannada. Use INR for amounts. Personal data rule: Digital Personal Data Protection Act 2023. Skills frame to cite: National Skills Qualifications Framework (NSQF) and the national credit framework.

Netherlands (Eindhoven area)

Language: Dutch, English. Use EUR for amounts. Personal data rule: EU GDPR (Dutch: AVG), supervised by the Autoriteit Persoonsgegevens. Skills frame to cite: the Dutch qualification framework (NLQF) linked to the European Qualifications Framework.

UAE (Dubai and Abu Dhabi)

Language: Arabic, English. Use AED for amounts. Personal data rule: Federal Decree-Law No. 45 of 2021 (personal data protection). Skills frame to cite: the emirate education and training regulators (for example KHDA in Dubai) and the national qualifications framework.

Brazil (Sao Paulo)

Language: Portuguese (Spanish and English support). Use BRL for amounts. Personal data rule: LGPD (Lei Geral de Protecao de Dados). Skills frame to cite: the national technical-education catalogue and the national S-system training bodies.

Canada (Toronto)

Language: English, French. Use CAD for amounts. Personal data rule: PIPEDA, with provincial rules where they apply. Skills frame to cite: the provincial colleges framework and the national credential-recognition guidance.

United States

Language: English, Spanish. Use USD for amounts. Personal data rule: state privacy laws (for example California), and COPPA for children under 13. Skills frame to cite: state and community-college credit systems.

Singapore

Language: English, Mandarin, Malay, Tamil. Use SGD for amounts. Personal data rule: Personal Data Protection Act (PDPA). Skills frame to cite: the Singapore national skills frameworks and the national credit system.

Australia

Language: English. Use AUD for amounts. Personal data rule: the Privacy Act 1988 and the Australian Privacy Principles. Skills frame to cite: the Australian Qualifications Framework (AQF) levels.

Hong Kong (Eastern Asia)

Language: Chinese (Cantonese, Mandarin), English. Use HKD for amounts. Personal data rule: the Personal Data (Privacy) Ordinance. Skills frame to cite: the Hong Kong Qualifications Framework.

Georgia and Israel (Western Asia)

Language: Georgian, Hebrew, Arabic, English. Use GEL or ILS for amounts. Personal data rule: the personal data law of the country where the learner lives. Skills frame to cite: the national qualifications framework of that country.

Cayman Islands (Caribbean)

Language: English. Use KYD for amounts. Personal data rule: the Data Protection Act. Skills frame to cite: the local education and training framework.

Mexico

Language: Spanish, English. Use MXN for amounts. Personal data rule: the federal law on personal data held by private parties. Skills frame to cite: the national competency certification system and the education ministry levels.

next

Draft

Draft course. Written in our own words from our own training outlines; no third-party text is used. Not live.

More courses Join