Salesforce Practice Orgs and Safe Learning
How the Salesforce Platform Works introduced the environments Salesforce offers and what separates a production org from everything else. This chapter is the practical follow-through: getting yourself one of those environments, and building the habits that stop your practice from turning into a bad day at work.
That matters more than it sounds. Salesforce is unusually easy to change, and the changes take effect immediately. There is no build step and no deploy button between you and a live user. Deactivate the wrong user, tighten a setting that controls who can see which records, or add a rule that blocks people from saving, and they feel it straight away. Reading about that risk is not the same as having somewhere to meet it safely.
By the end of this chapter you’ll have a free Salesforce org of your own, a clear sense of what should and should not go into it, and a way to retrace your steps when something stops working. Every later chapter assumes you have somewhere to try things, so this is worth twenty minutes now.
🧭 Playground or Developer Edition?
Section titled “🧭 Playground or Developer Edition?”Most guidance presents these as two competing options, which makes the choice sound weightier than it is. It isn’t, and the reason is worth knowing:
A Trailhead Playground is a Developer Edition org with Trailhead-specific data and tools.
That’s Salesforce’s own description, and it changes the question. You are not choosing between a toy and a real environment. You are choosing whether you want the same underlying org with or without a Trailhead wrapper: a pre-installed managed package that Salesforce keeps updated, some sample data, and the plumbing that lets Trailhead check your hands-on challenges automatically.
So decide on how you intend to learn, not on which one is more capable.
| Factor | Trailhead Playground | Developer Edition |
|---|---|---|
| Underlying org | Developer Edition | Developer Edition |
| Created from | A Trailhead challenge, in a couple of clicks | The Developer Edition signup form |
| Checks Trailhead challenges | Yes | Yes, once connected to your profile |
| Extra content | Trailhead sample data and a managed package | Agentforce and Data 360 features, plus a Salesforce-created administrator account to clean up |
| Best for | Working through Trailhead alongside these guides | A personal org you intend to keep and build in without the Trailhead wrapper |
You can have up to 10 hands-on orgs connected to your Trailhead profile at once, though only one Playground can be created at a time.
My practical read: start with a Playground if you’re following Trailhead or still deciding. Its challenge checks give you useful feedback while you learn. Create a standalone Developer Edition when you want a personal org to keep building in without Trailhead’s added tooling.
🚧 Why a sandbox isn’t your answer yet
Section titled “🚧 Why a sandbox isn’t your answer yet”Sandboxes are the environment most people have heard of, and for learning on your own they are usually unavailable. A sandbox is a copy of an existing production org, so creating one requires a production org to copy and the permission to do it. Without an employer’s org behind you, there is nothing to copy.
Scratch orgs aren’t the answer here either. A scratch org is a disposable, source-driven environment created from a Dev Hub. It expires after seven days by default and can last no more than 30, so it is designed to be recreated for a development or testing task, not kept as your long-term learning org.
If you do have access to your organisation’s sandbox, be careful about treating it as practice space, and check which type it is before you assume anything about what’s in it. Developer and Developer Pro sandboxes copy your org’s metadata and internal user records, but not its business records. Partial Copy sandboxes bring a template-selected sample of production data. A Full sandbox can copy all production data or a subset selected through a sandbox template, so either data-bearing type can contain real customer records.
That distinction matters because the sandbox types differ enormously in what a mistake there would expose. Salesforce Data Mask is a paid add-on rather than something already switched on, so copied production data can remain unmasked. Either way it is your employer’s environment, governed by their access reviews rather than your curiosity.
Sandbox Strategy & Change Management covers sandbox types, refresh cycles, and release process properly. For now, learn in a free org that belongs to you.
🔑 Setting up your Salesforce practice org
Section titled “🔑 Setting up your Salesforce practice org”The mechanics are well covered by Salesforce, and there is no point repeating a click-path that changes. The Trailhead Playground Management module walks through creating, launching, and renaming orgs. What follows is what to do once you’re in.
-
Create the org. Follow the Trailhead module for a Playground, or use the Developer Edition signup form for a standalone org. Expect a few minutes, plus an email verification step for a Developer Edition.
-
Find your username and set a password. A Playground generates its username for you, and it will not be your email address. Save it to a password manager immediately, because losing track of it is an easy way to abandon a practice org you could still use.
With the current Developer Edition signup, the form asks for your work email but does not let you choose a username. Salesforce assigns one while provisioning the org, and the welcome email takes you through account verification and password creation. Save the username as soon as it appears.
You can change it later. Salesforce’s username rules still apply: it must be globally unique and look like an email address, but it does not need to be a working one. Your email remains a separate field on the user record and can be associated with accounts in more than one org.
-
Rename the org so you can tell it apart. Once you have three of these, “Trailhead Playground 2” tells you nothing. Name it for what you are doing in it.
-
Log in and confirm you can reach Setup. Salesforce may first show Assign Org Responsibilities and ask for a required Security Contact. In a personal practice org, the named contact will usually be you. The form asks for a company email or distribution list, and Salesforce’s guidance says to use a valid business address rather than a personal one, plus a direct phone number. Use genuine contact details here rather than invented practice data. If you’re not ready or do not have the right details to hand, choose Remind me in 1 week and return to it later. Salesforce’s Security Contact guidance explains the role.
Once you reach Lightning Experience, look for the gear icon in the top right. If Setup is there, you have the administrator access this series assumes.
-
Make one user licence available. Open Setup → Company Information and check the Salesforce user licences. Current Agentforce and Data 360 Developer Edition orgs include a Salesforce-created System Administrator, so follow Salesforce’s transfer and deactivation procedure if that account is present. When the cleanup is complete, or if you chose a Playground, confirm that one licence is available for the test user you’ll create in the next chapter.
-
Set a recurring monthly reminder to log in. This one looks like busywork and isn’t. The next section explains what it protects you from.
📅 Keeping the org alive
Section titled “📅 Keeping the org alive”Here is the fact that catches people out, and it is worth reading twice, because most of what you’ll find written about it online is out of date.
A Developer Edition org you sign up for today is subject to expiry after 45 days without a login. Salesforce’s Developer Org Expiration documentation describes 45 days as the inactivity threshold. When Salesforce flags the org as inactive, it emails the org administrators and gives them 14 days to log in and reactivate it. From day 15 after that flag, the org is permanently deleted and cannot be recovered. Sign up through developer.salesforce.com/signup and you land on the current Developer Edition with Agentforce and Data 360; both its signup terms and the expiration documentation use that 45-day threshold.
You will very often see 180 days quoted instead, and that figure is not wrong so much as out of date. It applies to what Salesforce now calls Developer Edition (Legacy), the older generation without Agentforce and Data 360. If you have an org from before the current edition launched in March 2025, you’re on the longer clock. If you are creating one now, you are not, and a good deal of otherwise reliable writing has yet to catch up.
Purpose-built preview and trial orgs are a separate matter again. Those come with short fixed lifetimes measured in days or weeks rather than an inactivity clock, and they tell you the expiry date when you create them.
A handful of orgs are exempt from expiry altogether, including those that have released a managed package, registered a namespace, or had a connected app created in them. None of those is likely to describe a learning org, so assume the clock applies to you.
Salesforce does not publish an expiry period for Trailhead Playgrounds specifically. Since a Playground is a Developer Edition org underneath, the reasonable assumption is that dormancy will eventually cost you one, and the monthly habit covers it either way.
🧪 What goes in your practice org
Section titled “🧪 What goes in your practice org”To give the hands-on Fundamentals chapters a shared context, several of them use a fictional Equipment Request process. An employee asks for a laptop, monitor, or phone; their manager approves or rejects the request; and IT fulfils anything approved. You do not need to build it yet. Data Model will show you how to represent the process in Salesforce, Customisation & Automation will turn it into a working app, and the Build a Salesforce App chapters rebuild it properly later, with the access model, approval, and reports a real one needs.
It works well for practice because the process makes sense without a briefing, while still exercising objects, relationships, access, automation, and reporting. More importantly here, it gives you a reason to invent data rather than borrow it, which is the habit worth forming now.
Keep real business and personal data out of a practice org. Required account and Security Contact details are the narrow exception; the records you use for exercises should be invented. Do not load a customer list, an export from your employer’s org, or your colleagues’ contact details as test users. A free org sits outside your organisation’s security controls, its access reviews, and its data-retention obligations. Nobody is auditing what you put there, which is precisely the problem. If you would need to ask permission to email a file to yourself, it does not belong in a personal learning environment.
Representative data is what you actually need, and it is a real skill. Invent ten employees with plausible names, a handful of equipment types with realistic costs, and a few requests in different states, including at least one that is awkward: a request from someone who has left, or one sitting unapproved for three weeks. Clean, uniform test data hides exactly the bugs that surface in production.
Two constraints shape how far you can take this, and both are much tighter than a real org:
- Data storage is 5 MB, and file storage is 20 MB. Most records, custom objects included, consume about 2 KB, so 5 MB works out at roughly 2,500 records before the org stops accepting new ones. That is ample for learning a data model and nowhere near enough to load a real export into. Rich text and long text push it up, so treat it as a ceiling rather than a promise, and check the real figure under Storage Usage in Setup, the same page you will use to diagnose a production org that has quietly filled up.
- You get two Salesforce user licences. Once only your own administrator account is using one, the other is available for a test user. A current standalone Developer Edition can initially use both because of its Salesforce-created administrator, which is why the cleanup step matters. The Developer Edition allocations are small by design, so plan on reusing that one test account and changing what it’s allowed to do, rather than creating a separate user for every kind of person in your scenario.
🔐 Turning on MFA before anyone makes you
Section titled “🔐 Turning on MFA before anyone makes you”Multi-factor authentication is where practice orgs and real orgs genuinely diverge, and the direction of that difference surprises most people.
Salesforce began technically enforcing MFA for employee users in production and sandbox orgs in July 2026, with the rollout phased by release group. Check Salesforce’s detailed rollout schedule for the date that applies to a particular org. The underlying requirement is drawn by org type:
| Org type | MFA for internal user-interface logins |
|---|---|
| Production orgs, and every sandbox type | Required |
| Scratch orgs, trial orgs, Developer Edition orgs, Trailhead Playgrounds | Not required |
This table is deliberately scoped to internal user-interface access. API and integration logins follow different authentication rules, and external Experience Cloud users sit outside this MFA requirement. Your practice org will not make you set up MFA, but the first production or sandbox environment you touch will.
There is a second layer too. In orgs where MFA is required, users Salesforce classifies as privileged must use a phishing-resistant verification method rather than any second factor, and the definition is broad enough to catch you. Holding the System Administrator profile qualifies on its own, as does any of the Author Apex, Customize Application, Modify All Data, or View All Data permissions. In Salesforce’s own words, most admins and developers count as privileged.
That is an argument for switching MFA on in your practice org deliberately, even though nothing is forcing you. You get to register a verification method and see the login experience before it is attached to a real job, and you learn what your users will go through when you enable it for them. Doing it for the first time under pressure, in an org where people are waiting to log in, is a worse introduction.
Trailhead’s User Authentication module provides the current setup path. Its MFA hands-on challenge requires a brand-new Trailhead Playground, and Trailhead warns that an existing org or Playground can cause verification problems. If you chose a standalone Developer Edition, follow the same setup steps there for practice, but do not expect Trailhead to verify the challenge in that org. In either environment, sign out and sign in again. Seeing the verification challenge confirms that MFA is active for your account.
📜 Recording what you changed
Section titled “📜 Recording what you changed”The reason to keep notes in a practice org is not tidiness. It’s that you will break something, and the fastest route back is knowing what you did.
Salesforce keeps a record for you. Setup Audit Trail logs configuration changes with the date, the user, and what changed, and it is available in Developer Edition. From Setup, enter View Setup Audit Trail in the Quick Find box.
Its limits are the interesting part:
- The page shows only the 20 most recent changes. An hour of clicking around will push the start of your session off the list.
- The Download button gives you the full history for the past 180 days as a file. It is the built-in way to see beyond those 20 entries from this page.
- After 180 days the records are deleted.
Twenty entries disappear faster than you would think, which is the practical case for keeping your own short note as you work: what you were trying to do, what you changed, and what happened. A few lines per session is enough. Org Health & Monitoring develops this into a real monitoring routine later in the series; right now the habit matters more than the method.
🚨 When an experiment goes wrong
Section titled “🚨 When an experiment goes wrong”Salesforce has no undo button. At some point a change of yours will break something else, and getting back is a deliberate act rather than a keystroke. Working out which recovery you need is the skill.
Undo the change. Most of the time this is enough, and the audit trail tells you what to reverse. Work backwards from the most recent entry.
Start a fresh org. Some experiments leave enough tangled configuration that tracing every dependency costs more than rebuilding. When you need a clean state, create a fresh Playground or Developer Edition org and rebuild from your notes. This is another argument for keeping those notes.
Be careful with Disconnect. This is one of the most consequential actions on your Trailhead profile, and the behaviour is asymmetric in a way that is easy to miss:
| Action | Trailhead Playground | Developer Edition |
|---|---|---|
| Disconnect from your Trailhead profile | Recovery needs a support case, and Salesforce does not guarantee the org still exists | Reconnect at any time |
What disconnecting actually removes is the link between the org and your Trailhead profile, which is where you would normally go to find it. Salesforce says orphaned Playgrounds are “purged over time, and may be inaccessible after a certain time period”, and that getting one reconnected means raising a case with no guarantee it still exists.
What the documentation doesn’t say is whether saved credentials still get you in during that window. A Playground is a Developer Edition org with its own login, so in principle they should, and the inactivity clock from earlier keeps running either way. Treat that as untested rather than a safety net: save the username and password before you disconnect anything, and copy out any work you would be annoyed to lose.
✅ Checkpoint
Section titled “✅ Checkpoint”Before moving on, sign out and run one final readiness check. It is easy to feel prepared while the original login tab is still open; the better test is whether you can return to the org and find your way around without relying on that session.
- Sign in again using the username and password you saved, then open Setup. If you enabled MFA, complete the second-factor challenge as part of this check.
- Open Company Information and confirm the org has a meaningful name and one Salesforce user licence available. If a standalone Developer Edition still has its Salesforce-created administrator, finish the transfer and deactivation procedure before continuing.
- Open
View Setup Audit Trailand find a recognisable change from your setup session. Add a one-line note outside Salesforce with the date, what you changed, and the result. Keep credentials in your password manager, not in this note. - Confirm the guardrails: you have a monthly login reminder, you completed the Security Contact prompt with genuine details or set a reminder to return to it, and you will use invented records rather than real business or personal data.
- Make a deliberate MFA decision. Either complete one successful MFA login now or record in the same note that you are deferring it. A free practice org does not require MFA, but practising here means your first enforced MFA login will not also be your first attempt.
You are ready when you can answer three questions without guessing: How will I get back into this org next month? What data is safe to use here? Where will I look first when a change breaks something? If the checks above pass and those answers are clear, the org is ready for the exercises ahead.
🎯 Final Thoughts
Section titled “🎯 Final Thoughts”A practice org gives you room to follow your curiosity without putting anyone else’s work or data at risk. Change a setting, test the result, and, when something breaks, use your notes and the audit trail to work out why. Repeating that cycle is how platform knowledge becomes practical judgement.
Two things carry forward from this chapter. The first is the boundary: real data belongs in real, governed environments, and a free org you signed up for on a Tuesday is not one of them. That instinct is what keeps you out of trouble long after you have stopped being a beginner. The second is the change record. Right now it protects an afternoon’s work. In a production org it is the difference between a five-minute rollback and a long conversation about what happened.
🚀 Next steps
Section titled “🚀 Next steps”Continue to Users to learn how user records, licences, profiles, and permission sets control what people can see and do. Your administrator access is working and one Salesforce user licence is ready for a test account, so you now have somewhere safe to explore the access decisions that cause so much confusion in real orgs.
Whichever path brought you here, the rest of Salesforce Fundamentals runs in menu order from this point. The Salesforce Admin Journey and Salesforce Developer Journey roadmaps pick the route up again at the end of the section.