M06 — Practice With Salesforce
There is a point where studying more stops giving you clarity and starts hiding the real problem: you have not built enough yet.
In Salesforce, practice should not only mean following instructions. It should help you think like someone who solves problems: understand a case, model data, configure a solution, test it and explain why you made those decisions.
You do not need to create the biggest project in the world. You need small, clear and explainable mini projects.
Something you can show. Something you can talk about in an interview. Something that proves you have not only read theory: you have touched the tool, made mistakes, fixed them and understood a little more about how it works.
This module is about turning study into evidence.
What you can do needs to be visible and explainable.
Practicing does not mean building a fictional multinational with twenty objects, eight flows, three dashboards and an epic name.
Practicing means choosing a small problem, understanding it well and building a simple solution you can explain.
One small finished thing is better than one huge half-built monster.
Why it changes the conversation
There is a big difference between saying:
I have done quite a lot of Trailhead.
And saying:
I built a small process in a Developer Org. The problem was this. I used these objects, these fields, this automation and this report. I changed this for this reason. And in a second version I would improve this.
The second sentence does not make you senior. But it proves something important: you have touched the platform, thought through the process and can defend what you built.
That separates you from many people who only consumed content.
The useful minimum
A good mini project can include:
- one business problem;
- one or two clear users;
- two or three objects;
- necessary fields;
- one simple automation;
- one report;
- one dashboard or visual summary;
- one short explanation.
Do not overcomplicate it.
In fact, trying to look senior by adding complexity often does the opposite.
Good practice does not shout “look how much I know”. It says: “I understand the problem and built something reasonable”.
If you come from sales
Create a simple commercial follow-up process.
Include:
- leads;
- accounts and contacts;
- opportunities;
- stages;
- qualification fields;
- pipeline report;
- sales dashboard;
- follow-up automation.
Business story:
The sales team needs visibility on open opportunities, next steps and basic forecasting so it does not depend on memory, spreadsheets or scattered messages.
If you come from sales, you have an advantage. You already understand commercial pressure, customers, pipeline and awkward end-of-month conversations.
That is value.
If you come from support
Create a basic case management process.
Include:
- cases;
- category;
- priority;
- status;
- queue;
- automatic assignment;
- open cases report;
- dashboard by priority or owner.
Business story:
The support team needs to prioritize urgent incidents, distribute work and keep customer context visible to respond better.
Here you are not “making fields”. You are modeling a way of working.
If you come from operations, administration or projects
Create an internal request process.
Include:
- Request object;
- type;
- status;
- owner;
- priority;
- approval or assignment;
- pending requests report;
- bottleneck dashboard.
Business story:
The team needs to know which requests are pending, who owns them, how long they take and where the process gets stuck.
This connects well with operations, administration, project or coordination backgrounds.
If you want to touch data or AI later
Once you have the base, you can build more modern mini projects:
- preparing customer data for segmentation;
- designing a small Data Cloud use case;
- defining what an agent should do;
- documenting which data it needs;
- deciding when it should hand off to a person;
- explaining limits, risks and maintenance.
Real AI is not “add an agent”. It is designing what it solves, with what information, with what limits and how it is maintained.
That is why the base still matters.
How to document it
Create a project sheet:
| Field | What to write |
|---|---|
| Name | Clear and simple |
| Business problem | What pain it solves |
| Users | Who would use it |
| Objects | What main data is involved |
| Key fields | What information you capture |
| Automation | What rule or process you created |
| Reports | What visibility it provides |
| Dashboard | What helps decision-making |
| Changes | What you adjusted while testing |
| Future improvements | What you would build in version two |
This sheet helps with LinkedIn, CV, portfolio and interviews.
And it helps with something more important: thinking better.
Before moving on
Choose one mini project and write this before building:
- what problem it solves;
- who the user is;
- which objects it will use;
- which fields it needs;
- which automation it will include;
- which report it will show;
- which dashboard it will provide;
- how you would explain it in five sentences.
Practice does not replace professional experience. But it helps you compete much better.
Above all, it gives you a story.