Salesforce Fundamentals: Part 4 - Customisation & Automation

Published 26/09/2025 & Updated 29/05/2026

This is where Salesforce starts to feel less like a database and more like a system built around the way people actually work. For me, this is also where the platform starts to get much more interesting, because small design choices begin to have a very visible impact on the user experience. A good data model gives you structure, but customisation and automation turn that structure into screens, guided processes, and repeatable actions users can rely on every day.

In this chapter, you’ll move from “what data do we store?” to “how should people use it?” You’ll configure apps, shape object experiences, and introduce automation patterns that help the org scale without relying on manual follow-up, while staying grounded in strong data management practices.

---

🧰 Basic Customisation: Building Simple Apps and Objects

Salesforce is powerful because you can tailor it quickly with point-and-click tools.

• Custom Apps group tabs, objects, and pages by team workflow.
• Custom Objects capture business concepts not covered by standard CRM objects.

When done well, customisation reduces noise for users and helps teams work in one focused workspace.

⚙️ Core customisation tools

• Lightning App Builder for page layouts and app experiences.
• Object Manager for fields, validation rules, relationships, and metadata settings.

Together, these tools let admins and developers translate business requirements into maintainable configuration.

🧱 A practical build sequence

1. Clarify the process and required records.
2. Model objects and fields.
3. Configure layouts and app navigation.
4. Add validation for key quality rules.
5. Test with realistic user profiles.

Keep customisation intent visible

Name fields, flows, and pages in a way that reflects business intent. Clear naming makes future maintenance and handovers much easier.

Lightning App Builder Build and customise Lightning pages with drag-and-drop tools.

Quick Start: Lightning App Builder Hands-on project for building an app interface without code.

---

🛠️ A Practical Example: Building an Equipment Request App

Let’s walk through a concrete example that shows how customisation and automation turn a manual process into a working solution.

Scenario: Your team needs a simple way to request laptops, monitors, or other equipment. Currently, people email their manager, who forwards requests to IT. Requests get lost, there’s no audit trail, and managers waste time tracking things down.

1. Create a custom object — Instead of forcing people to use the standard CRM objects, create a new object called Equipment Request with fields like:

   • Text field: Equipment Type (laptop, monitor, keyboard, and so on)
   • Picklist: Priority (Standard, Urgent, Executive)
   • Lookup: Employee (who’s requesting)
   • Date field: Required Date
   • Status picklist: New → In Review → Approved → Fulfilled → Rejected This object captures exactly what the business needs, nothing more and nothing less.

2. Configure the app experience — Create a custom Equipment App that shows only the relevant tabs: Equipment Request, Employee, and maybe Contacts. Inside the app, configure a Lightning page with:

   • A list view showing all pending requests
   • A record page layout with the key fields visible
   • A related list showing equipment history for each employee Now users have a focused workspace and don’t get distracted by sales objects they never use.
   

   A focused custom app gives users a clearer workspace and makes the process easier to follow.

3. Add validation rules — Make sure data quality stays high with simple rules:

   • Required Date can’t be in the past
   • Priority must be “urgent” if the request is for executive staff
   • Equipment Type is required before the record moves beyond the New status These rules prevent bad data from entering the system and force users to think through their requests.

4. Automate with Flow — This is where the process becomes self-service. Create a record-triggered Flow that runs when a new Equipment Request is created:

   1. Get the employee’s manager from the Employee lookup
   2. Send an approval request to the manager through email and an in-app notification
   3. If approved, automatically create a task for IT to fulfil the request
   4. If rejected, update the status and notify the employee with a reason Now the whole process runs automatically. No email chains, no manual follow-up, and no lost requests.

5. Test with realistic profiles — Finally, test the app with different user profiles:

   • An employee who can create requests and view their own status
   • A manager who can approve or reject requests for their team
   • An IT administrator who can see all requests and update fulfilment status Each profile sees only what they need and nothing more.

Start small, then scale

This example shows a simple equipment request, but the same pattern applies to project intake, case escalation, expense approvals, or any business process. Build the minimum viable version first, then add complexity only when users actually need it.

---

🤖 Introduction to Automation

Automation is where Salesforce starts to multiply team productivity. Instead of relying on manual steps, you define rules and actions that run consistently in the background.

🌟 Why automation matters

• Consistency: processes run the same way every time.
• Speed: users do less repetitive data entry.
• Data quality: updates and checks happen automatically.
• Scale: operations grow without linear admin effort.

🧭 Core automation tools

Flow is Salesforce’s primary declarative automation tool, and the one you should prioritise learning deeply in Part 3 — Automation.

• Screen Flows for guided, user-driven processes.
• Record-Triggered Flows for save-time automation.
• Scheduled Flows for time-based jobs.
• Approval Processes for governed review paths.
• Legacy tools like Workflow Rules and Process Builder may still appear in existing orgs.

🔮 Where this is heading

Salesforce continues to blend automation with AI-assisted workflows, including Agentforce action patterns that call Flow for data retrieval, updates, and orchestration.

Clicks before code still applies

For many business workflows, Flow is the right first choice. Move to Apex only when logic, scale, or integration complexity requires it.

🧭 Choosing Between Flow, Approval Processes, and Apex

Not every automation belongs in Flow. Pick the right tool and your org stays easier to maintain. Pick the wrong one and you’ll fight the platform every time Salesforce releases a new feature.

🔄 When Flow is the right choice

Flow handles most business automation without code. Start here when:

• You need to update records automatically after a save
• You want to guide users through a multi-step process with a screen
• You need scheduled actions like sending reminders or updating old records
• Your logic fits within Flow’s declarative capabilities (updates, creates, lookups, simple conditions)

Flow is Salesforce’s primary automation tool and the one you should invest in deeply. For many workflows, it’s the right first choice before you even think about code.

✅ When Approval Processes make more sense

Approval Processes are built specifically for governed review paths. Use them when:

• You need a formal, auditable approval chain
• Multiple people must approve in a specific order
• Approvers need to see a history of who approved what and when
• You want to lock records during the approval process

New approval processes are built on Flow, so prefer the standard approval framework unless you have a very specific requirement it can’t meet. The built-in path is more maintainable and gives better visibility into approval history.

💻 When you actually need Apex

Move to Apex when your automation hits one of these boundaries:

Situation	Why Flow struggles	Apex advantage
Very large data volumes	Flow has governor limits on records processed	Apex handles bulk operations more efficiently
Complex calculations or external API calls	Flow expressions get unwieldy	Apex gives you full programmatic control
Highly custom integration patterns	Flow’s integration tools are limited	Apex can call any API with custom logic
Recursion or complex transaction control	Flow can get into recursive loops	Apex gives you explicit control over transaction boundaries
Logic that repeats across multiple objects	You’d need duplicate Flows	Apex can be reused through a single service class

Clicks before code still applies. For many business workflows, Flow is the right first choice. Move to Apex only when logic, scale, or integration complexity requires it.

Don't fight the platform

If you find yourself building a Flow with 20+ decision branches, dozens of variables, and complex error handling, step back. That’s often a sign the logic is better suited for Apex. A well designed Apex service class is more maintainable than a Flow trying to do everything.

---

🎯 Final Thoughts

For me, this is the point where Salesforce stops being a basic platform and starts becoming a system people rely on. It is also a part of Salesforce I find most interesting, because small design choices can have a huge effect on how people experience the platform day to day. A well designed app, a clear record page, or a thoughtfully built Flow can make everyday work faster, more consistent, and much less frustrating.

This is also where good design decisions start to show their value. If your object model is clear, your layouts are focused, and your automation reflects how the business actually operates, Salesforce feels intuitive. If those pieces are rushed or overcomplicated, users notice that too.

In practice, the best solutions are usually the ones that users barely have to think about. They fit the process, reduce manual effort, and give teams confidence that the data in Salesforce can be trusted.

🚀 Next steps

Once records are being captured properly and processes are running consistently, the next question is simple: what is all that activity telling you? That’s where reporting becomes essential.

In Reports & Dashboards, you’ll learn how to turn the data created by your apps and automations into useful insight. That means tracking performance, spotting issues earlier, and giving teams something more valuable than raw visibility.

---

About the Author: Based in New Zealand, I’m a Salesforce Platform Architect who has worked across administration, custom development, and large-scale org design, holding the Platform Developer, Application Architect, and System Architect credentials. However far you go on the platform, the work keeps coming back to the fundamentals: get these foundations right and everything you build on top is simpler, more secure, and easier to maintain. That is the lens I bring to customisation and automation. What you find here is project-tested Salesforce guidance kept deliberately practical, backed by official Salesforce documentation wherever a platform behaviour or best practice needs supporting.

---

📚 Resources

Build Flows with Flow Builder Learn core Flow patterns for business automation.

Approve Records with Approval Processes Understand structured approval patterns in Salesforce.

Lightning App Builder Create focused user experiences with point-and-click app design.