Test a Salesforce Sales Pipeline

Run a full manual test cycle against a Salesforce Sales Cloud pipeline.

Introduction

30 Second Summary

When you test a traditional application, you test code. In Salesforce, you test configuration: validation rules built from formulas, automation Flows assembled with drag-and-drop logic, and permissions layered across user profiles.

In this project, you will configure a realistic Sales Cloud Opportunity pipeline, then execute a structured test cycle against it. You will find a deliberate configuration gap, diagnose its root cause in Setup, and document it the way a Salesforce Test Analyst would on a real engagement.

What You'll Build

You will run a complete test cycle against a live Salesforce pipeline, watch a validation rule block invalid data in real time, see a Flow auto-create a Contract record for a high-value deal, and document a defect you uncover through boundary testing.

By the end of this project, you'll have:

A working Opportunity pipeline with a custom picklist field, a validation rule enforcing Amount > 0 on Closed Won deals, and a Flow that auto-creates Contracts for high-value wins.
A structured set of test cases covering positive paths, negative paths, boundary conditions, and automation triggers.
A documented defect report where you discover a validation gap, trace it to its root cause in the declarative configuration, and write up the finding.
Firsthand experience testing as different user profiles to observe how Salesforce permissions change what is visible and editable.
Secret Mission: Create and test a missing validation rule yourself, then run regression tests to confirm nothing else broke.

Are there any prerequisites?

No prior Salesforce experience is required. This project includes full setup instructions for the free Salesforce Developer Edition org you will use. All you need is a web browser and a real email address for account verification.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters for your move into Salesforce testing.

Set Up Your Salesforce Developer Edition

To test a Salesforce pipeline, you need a live Salesforce environment to configure and run tests against. The free Developer Edition gives you full admin access to a Sales Cloud org with no time limit and no credit card required.

In this step, you will sign up for your own Developer Edition org, confirm it is running in Lightning Experience, and verify that the Opportunity object is available for the pipeline you will build.

In this step, get ready to:

Sign up for a free Salesforce Developer Edition account.
Verify your org is working and locate the Opportunity object in Object Manager.
Open the Sales app and confirm the Opportunities tab is accessible.

Sign up for a free Salesforce Developer Edition

The Developer Edition is a fully functional Salesforce org that you own and administer. It includes Sales Cloud, the same tools production orgs use, and it stays active as long as you log in at least once every 45 days.

Open https://developer.salesforce.com/signup in your browser.
Fill in your First Name and Last Name.
Enter a real email address you can access in the Email field.
Create a Username in email format (for example, yourname@testanalyst.dev).

What is the Username field?

Your Salesforce username must look like an email address, but it does not need to be a real, working email. It is simply your login identifier for this org.

Check the Master Subscription Agreement checkbox and click Sign me up.
Check your email inbox for the verification message from Salesforce.
Click Verify Account in the email.
Set your password when prompted.

You are now logged into your Developer Edition org in Lightning Experience. You should see the Salesforce home page with the Setup gear icon in the top-right corner.

Don't see the verification email?

Check your spam or junk folder. The email comes from Salesforce and may take 2-3 minutes to arrive.

If you used a work email, your organisation's mail filter may have blocked it. Try signing up again with a personal email address.

help me troubleshoot my Salesforce Developer Edition signup email not arriving

Verify your org is working and orient yourself

The Setup area is where all Salesforce configuration lives. You will spend a lot of time here as a Test Analyst, inspecting validation rules, Flows, and field settings.

Click the gear icon in the top-right corner of the page.
Select Setup from the dropdown.
In the Quick Find box on the left sidebar, type Object Manager.
Click Object Manager when it appears in the results.
Scroll down the list of objects and confirm you see Opportunity.

What is Object Manager?

Object Manager is where you view and configure the structure of Salesforce objects (like Opportunity, Account, Contact). Each object has fields, validation rules, page layouts, and relationships that you can inspect and modify.

As a Test Analyst, you will use Object Manager constantly to understand what configuration you are testing against.

Click Home in the top-left corner to return to the Lightning home page.

Open the Sales app and confirm sample data

Salesforce organises features into apps. The Sales app gives you access to Opportunities, Accounts, and other objects you will test against.

Click the App Launcher (the grid icon in the top-left corner).
Type Sales in the search box.
Click Sales to open the Sales app.
Click the Opportunities tab in the navigation bar at the top.

You should see the Opportunities list view. It may show Recently Viewed with no records yet. That is expected for a brand-new org.

Don't see the Opportunities tab?

Make sure you selected the Sales app from the App Launcher, not a different app. The Opportunities tab is part of the Sales app navigation.

If the tab still does not appear, click the pencil icon at the far right of the navigation bar, find Opportunities in the available items list, and add it.

help me find the Opportunities tab in Salesforce

Your Salesforce environment is live and ready. Next up, you will configure the Opportunity pipeline with a custom field and a validation rule that you will later test against.

Configure the Opportunity Pipeline

Your Salesforce org is set up and ready. Now it's time to build the pipeline you'll be testing.

Before you can test, you need something to test. In this step, you'll add a custom field and a validation rule to the Opportunity object. This is exactly the type of declarative configuration you'll encounter on real Salesforce projects.

In this step, get ready to:

Create a custom picklist field on the Opportunity object.
Build a validation rule that blocks invalid data on Closed Won deals.
Test the configuration by triggering the validation error.

Create a custom picklist field on Opportunity

Every sales team tracks deal-specific data beyond what Salesforce provides out of the box. You'll add a "Deal Risk Level" picklist field to give reps a way to flag how risky a deal is.

Click the gear icon (top-right) in your Salesforce org.
Select Setup. This opens Setup in a new browser tab.
Click Object Manager in the navigation bar at the top of the Setup page.
Scroll down and click Opportunity.
Click Fields and Relationships in the left sidebar.
Click New.

Where are you now?

You're in the New Field wizard for the Opportunity object. This wizard walks you through choosing a field type, naming it, setting values, and assigning security. Each screen is one step of that wizard.

Select Picklist as the Data Type.
Click Next.
Enter Deal Risk Level in the Field Label field.
Select Enter values, with each value separated by a new line.
Type these three values in the text box, one per line: Low, Medium, High.
Click Next.
Accept the default field-level security settings and click Next.
Click Save.

You're returned to the Fields and Relationships list. Scroll down and confirm you can see Deal Risk Level in the list.

Don't see Deal Risk Level in the list?

The list is alphabetical. Scroll to the "D" section.
If it's not there at all, click New and walk through the wizard again. Make sure you clicked Save on the final screen (not just Next).

help me troubleshoot my custom field not appearing

Create a validation rule requiring Amount > 0 on Closed Won

A validation rule stops users from saving a record when specified conditions are met. You'll create one that prevents an Opportunity from being marked "Closed Won" if the Amount is zero.

You should still be in Object Manager with Opportunity selected. Click Validation Rules in the left sidebar.
Click New.
Enter Amount_Required_For_Closed_Won in the Rule Name field.
Confirm the Active checkbox is checked.
In the Error Condition Formula box, enter the formula below:

ISPICKVAL(StageName, "Closed Won") && Amount = 0

What does this formula do?

The formula evaluates to TRUE when the error should fire. ISPICKVAL(StageName, "Closed Won") checks whether the Stage picklist equals "Closed Won". The && means AND. Amount = 0 checks whether the Amount is zero.

When both conditions are true simultaneously, Salesforce blocks the save and displays your error message.

In the Error Message field, enter: Amount must be greater than zero for Closed Won opportunities.
Set Error Location to Top of Page.
Click Check Syntax to verify there are no formula errors.
Click Save.

You're returned to the Validation Rules list. You should see Amount_Required_For_Closed_Won listed with a green checkmark indicating it's active.

Seeing a syntax error when you click Check Syntax?

Make sure StageName is one word with a capital S and capital N. This is the API name of the Stage field.
Check that you used straight double quotes around "Closed Won", not curly/smart quotes. Copy-pasting from some sources introduces curly quotes.
Verify && has no spaces between the ampersands.

help me fix my validation rule syntax error

Test the validation rule with a new Opportunity

The rule is active. Time to prove it works by trying to save data that should be blocked.

Switch to your original Salesforce tab (the one with the Sales app).
Click the Opportunities tab in the navigation bar.
Click New to create a new Opportunity.
Fill in these fields:

Before you click Save, predict what will happen. Will the record save successfully, or will something stop it?

Click Save.

You see the validation error message at the top of the page: "Amount must be greater than zero for Closed Won opportunities." The record does not save. Your rule is working.

Why did the error appear at the top?

You set the Error Location to "Top of Page" when creating the rule. Salesforce also lets you attach errors to a specific field, which places the message directly below that field. Top of Page is easier for testers to spot during test execution.

Now fix the data so it passes. Change Amount to 50000.
Set Deal Risk Level to Medium.
Click Save.

The record saves successfully. You now have a working Opportunity with both the custom field populated and the validation rule confirmed.

Still seeing the error after changing Amount to 50000?

Make sure the Stage is still set to Closed Won. If you accidentally changed it, the Amount check no longer applies but other required fields might be missing.
Confirm you typed 50000 with no currency symbol or commas. Salesforce auto-formats it after save.

help me get my Opportunity to save

Your pipeline has teeth now. A custom field for tracking risk, and a validation rule that enforces data quality. Next up, you'll add automation that creates a Contract record when high-value deals close.

Build the Automated Flow

Your validation rule is catching bad data on the way in. Now it is time to add automation that takes action when good data arrives.

Salesforce Flows are one of the most common sources of defects on real projects. As a Test Analyst, you need to understand how Flows work so you can design test cases that verify automation fires correctly and does not fire when it should not.

In this step, get ready to:

Build a record-triggered Flow that auto-creates a Contract when a high-value deal closes.
Configure trigger conditions and a Create Records action in Flow Builder.
Activate the Flow and verify it fires on a new Opportunity.

Create a record-triggered Flow that generates a Contract for high-value Closed Won deals

The business scenario: whenever an Opportunity reaches Closed Won with an Amount over 25,000, a draft Contract should be automatically created. You will build this automation, then test it in Step 4 to verify it fires correctly at the right boundaries.

Click the gear icon (top-right) and select Setup.
In the Quick Find box, type Flows and select Flows under Process Automation.
Click New Flow.
In the dialog that appears, select Record-Triggered Flow and click Create.

The Configure Start panel opens automatically. This is where you define what object the Flow watches and what conditions must be met for it to fire.

Set Object to Opportunity.
Set Trigger the Flow When to A record is created or updated.
Set Condition Requirements to All Conditions Are Met (AND).
Set the first condition: Field = Stage, Operator = Equals, Value = Closed Won.
Click Add Condition.
Set the second condition: Field = Amount, Operator = Greater Than, Value = 25000.

Why two conditions?

The Flow only fires when BOTH conditions are true at the same time. The deal must be Closed Won AND the Amount must exceed 25,000. This means a Closed Won deal worth exactly 25,000 will NOT trigger the Flow. That boundary creates an excellent test case later.

Under When to Run the Flow for Updated Records, select Only when a record is updated to meet the condition requirements.
Under Optimize the Flow For, select Actions and Related Records.
Click Done.

You should now see the Flow Builder canvas with your configured Start element displayed. The canvas shows the trigger conditions you just set.

What does "Only when updated to meet conditions" mean?

This setting means the Flow fires only once, at the moment a record transitions INTO the matching state. If a record already meets the conditions, editing it again will not re-fire the Flow.

This prevents duplicate Contracts from being created every time someone edits a Closed Won Opportunity.

Don't see the canvas?

If the Start panel closed without saving, click the Start element on the canvas to reopen its configuration. Verify the Object is set to Opportunity and both conditions appear.

help me configure the Start element for my record-triggered Flow

Add the Create Records action

With the trigger configured, you now need to tell the Flow what to DO when the conditions are met. You will add a Create Records action that generates a draft Contract linked to the Opportunity's Account.

On the Flow canvas, click the + icon on the path below the Start element.
Scroll to the Data section and click Create Records.
Set Label to Create Draft Contract.
Set How to Set Record Field Values to Manually.
Set Object to Contract.
Under Set Field Values: set Field = Account ID, Value = select Triggering Opportunity > Account ID (select the option without a trailing > symbol).
Click Add Field. Set Field = Status, Value = Draft.
Click Done.

Your canvas now shows the Create Draft Contract action connected below the Start element.

What does this action do?

When the Flow fires, it creates a new Contract record with the Account pulled from the triggering Opportunity. The Status is set to Draft so someone still needs to review and activate the Contract before it becomes binding.

Can't find Account ID in the value picker?

When setting the Account ID value, look for the resource dropdown and select the triggering Opportunity record. Then select the Account ID field from it. Make sure you pick the one that does NOT have another > symbol after it.

help me set the Account ID field value in my Flow's Create Records action

Save, activate, and test the Flow

Click Save in the top-right of Flow Builder.
Set Flow Label to High Value Closed Won Contract.
Set Description to Creates a draft contract when an opportunity is closed won with amount over 25000.
Click Save.
Click Activate in the top-right of Flow Builder.

Your Flow is now live. Any Opportunity that is created or updated to meet the conditions (Stage = Closed Won AND Amount > 25,000) will trigger a new Contract.

Why won't the existing Test Deal Alpha trigger this Flow?

Your "Test Deal Alpha" Opportunity already has Stage = Closed Won and Amount = 50,000. It met the conditions BEFORE the Flow was activated. The "Only when updated to meet conditions" setting means the Flow only fires at the moment a record transitions into the matching state.

To test the Flow, you need to create a brand new Opportunity that enters the matching state for the first time.

Click the App Launcher (grid icon, top-left), search for Sales, and select the Sales app.
Click the Opportunities tab in the navigation bar.
Click New to create a new Opportunity.
Set Opportunity Name to Test Deal Beta.
Set Close Date to any future date.
Set Stage to Closed Won.
Set Amount to 30000.
If your org has existing Accounts, select one in the Account Name field. If none exist, leave it blank.

Before you click Save, think about what you expect to happen. Will the Flow fire for this new record? What should appear on the Opportunity after you save it?

Click Save.
On the Opportunity record page, click the Related tab.
Look for a Contracts section in the related lists.

You should see a Contract record with Status = Draft. The Flow fired because this new Opportunity was created already meeting both conditions (Stage = Closed Won and Amount = 30,000, which is greater than 25,000).

Don't see a Contract in the Related tab?

Confirm your Flow is Active: return to Setup > Flows and check the status column shows Active next to "High Value Closed Won Contract".
Verify the Amount on Test Deal Beta is greater than 25,000 (not equal to 25,000).
Check that the Stage is exactly Closed Won (not Closed/Won or another variation).
If the Contracts section does not appear in the Related tab, scroll down to check all related lists. Some page layouts group related lists differently.

help me troubleshoot why my record-triggered Flow did not create a Contract

Your automation pipeline is complete. You have a validation rule blocking bad data and a Flow creating Contracts for high-value wins. Next up, you will put on your Test Analyst hat and run a structured test cycle against everything you have built.

Execute Your Test Cycle

Your pipeline is fully configured. You have a custom field, a validation rule, and an automated Flow all working together on the Opportunity object.

Now you shift from builder to tester. You will design and execute test cases that specifically target how Salesforce declarative features can fail. This is not "does the button work" testing. It is testing configuration logic, formula evaluation, automation trigger conditions, and boundary values.

In this step, get ready to:

Design six test cases targeting Salesforce-specific patterns like validation formulas, boundary conditions, and Flow trigger logic.
Execute each test case and record pass/fail results.
Document a configuration defect with root cause analysis pointing back to declarative Setup.

Design your test cases targeting Salesforce-specific scenarios

Generic functional testing checks whether a button works or a page loads. Salesforce-specific testing targets the declarative configuration layer: formula logic in validation rules, trigger conditions on Flows, and boundary values at the exact thresholds where behaviour changes.

Create a simple test case document on your computer. Use any format you prefer: a text file, a spreadsheet, or a notepad app.
Add the following six test cases to your document, including the expected result for each:

TC01: Positive path + automation
  Stage = Closed Won, Amount = 75000
  Expected: Saves successfully AND Contract auto-created

TC02: Validation rule fires
  Stage = Closed Won, Amount = 0
  Expected: Error message displayed, record does not save

TC03: Boundary value (lower)
  Stage = Closed Won, Amount = 25000 (exactly)
  Expected: Saves but NO Contract created
  (Flow condition is Greater Than 25000, not greater-than-or-equal)

TC04: Boundary value (upper)
  Stage = Closed Won, Amount = 25001
  Expected: Saves AND Contract auto-created

TC05: Negative path for automation
  Stage = Prospecting, Amount = 100000
  Expected: Saves, NO Contract created (wrong stage)

TC06: Gap test
  Stage = Closed Lost, Amount = 0
  Expected: What happens?

Why are these Salesforce-specific?

TC01-TC02 test the validation rule formula logic. The formula uses ISPICKVAL() and && operators that evaluate at save time. A typo in the formula means the rule silently never fires.

TC03-TC04 target the exact boundary of the Flow's "Greater Than 25000" condition. Off-by-one errors in Flow conditions are one of the most common automation defects.

TC05-TC06 test what the configuration does NOT cover. Real defects often hide in the scenarios nobody thought to configure.

Execute each test case and record results

For each test case, you will create a new Opportunity with the specified values and record the actual result next to your expected result.

In the Sales app, click the Opportunities tab in the navigation bar.
Click New to create a new Opportunity.
Enter: Opportunity Name = TC01 Positive Path, Close Date = any future date, Stage = Closed Won, Amount = 75000.
Click Save.

The record saves successfully. Now verify the automation fired.

Click the Related tab on the Opportunity record.
Look for a Contract in the Contracts section. You should see one with Status = Draft.
Record in your test document: TC01 = Pass. Record saved AND Contract auto-created.

Now execute TC02 to confirm the validation rule fires.

Click the Opportunities tab, then click New.
Enter: Opportunity Name = TC02 Validation Fires, Close Date = any future date, Stage = Closed Won, Amount = 0.
Click Save.

You should see the error message "Amount must be greater than zero for Closed Won opportunities." at the top of the page. The record does not save.

Record in your test document: TC02 = Pass. Validation error displayed, record blocked.
Click Cancel to discard the record.

Why boundary testing matters for Flows

The next two test cases (TC03 and TC04) target the exact threshold of your Flow's condition: Amount Greater Than 25000. TC03 tests whether Amount = 25000 exactly triggers the Flow. TC04 tests whether Amount = 25001 does.

If someone configured "Greater Than or Equal To" instead of "Greater Than", TC03 would produce a Contract when it should not. This is one of the most common misconfiguration defects in Salesforce Flows.

Click New on the Opportunities list.
Enter: Opportunity Name = TC03 Boundary Lower, Close Date = any future date, Stage = Closed Won, Amount = 25000.
Click Save.
Click the Related tab. Verify there is NO Contract in the Contracts section.
Record: TC03 = Pass. Saved successfully, no Contract created. The boundary holds.

Click Opportunities tab, then click New.
Enter: Opportunity Name = TC04 Boundary Upper, Close Date = any future date, Stage = Closed Won, Amount = 25001.
Click Save.
Click the Related tab. Verify a Contract with Status = Draft appears in the Contracts section.
Record: TC04 = Pass. Saved AND Contract auto-created. The Flow fires at 25001, exactly one above the threshold.

Now execute TC05 to confirm the Flow does not fire for the wrong stage.

Click Opportunities tab, then click New.
Enter: Opportunity Name = TC05 Wrong Stage, Close Date = any future date, Stage = Prospecting, Amount = 100000.
Click Save.
Click the Related tab. Confirm NO Contract was created despite the Amount being 100000.
Record: TC05 = Pass. The Flow correctly ignores records where Stage is not Closed Won.

Five test cases executed, five passes. Everything the configuration covers is working correctly. Now for TC06.

Before you run this one, pause and predict: what do you think will happen when you try to save an Opportunity with Stage = Closed Lost and Amount = 0? Will any validation rule stop you?

Click Opportunities tab, then click New.
Enter: Opportunity Name = TC06 Gap Test, Close Date = any future date, Stage = Closed Lost, Amount = 0.
Leave all other fields blank. No Close Reason, no Deal Risk Level.
Click Save.

The record saves successfully. No error, no validation message, no warning. You just saved a lost deal with no explanation of why it was lost and no amount recorded.

This is not a bug in your testing. This is a configuration gap. A real business would require a Close Reason when losing a deal. The current configuration simply does not enforce it.

Record: TC06 = Gap identified. Closed Lost with Amount = 0 and no Close Reason saves without error.

Why did the validation rule not fire?

Look at the validation rule formula: ISPICKVAL(StageName, "Closed Won") && Amount = 0. It only evaluates to TRUE when Stage equals Closed Won. For any other Stage value, the first condition is FALSE, so the entire formula is FALSE and the error never fires.

This is the root cause: no validation rule exists for the Closed Lost stage. The gap is not in how the existing rule works. It is in what was never configured in the first place.

Document the defect you found

Finding the gap is half the job. Documenting it so a developer or admin can reproduce and fix it is the other half. A Salesforce Test Analyst writes defect reports that trace back to the specific declarative configuration that needs changing.

In your test document, add a defect report section with the following details:

DEFECT REPORT

Title: Validation gap - Closed Lost opportunities can be saved without a Close Reason
Severity: Medium

Steps to Reproduce:
1. Create a new Opportunity
2. Set Stage to Closed Lost
3. Leave Amount at 0 and no Close Reason field populated
4. Click Save

Expected Result:
System should require a Close Reason when Stage is Closed Lost

Actual Result:
Record saves successfully with no close reason

Root Cause:
No validation rule exists for the Closed Lost stage.
The current rule (Amount_Required_For_Closed_Won) only covers Closed Won.

Recommended Fix:
Create a new validation rule on Opportunity that fires when
Stage = Closed Lost and Close Reason is blank.

Why include root cause in a Salesforce defect report?

In general software testing, root cause often requires a developer to debug application code. In Salesforce, a Test Analyst can trace the root cause themselves by inspecting Setup. You looked at the validation rule formula and saw it only checks for Closed Won.

This is one of the biggest differences in a Salesforce testing role. The "code" is visible in Setup as declarative configuration, so your defect reports can pinpoint exactly where the fix goes.

Confirm you can trace the root cause yourself: click the gear icon, select Setup, open Object Manager, select Opportunity, then click Validation Rules.
Click Amount_Required_For_Closed_Won to view the rule.
Read the Error Condition Formula. You can see it only references "Closed Won". There is no rule for "Closed Lost" anywhere in the list.

You have now completed a full test cycle: six test cases designed, executed, and documented. Five passed as expected. One revealed a configuration gap that you diagnosed and reported with a specific root cause and recommended fix.

TC01 saved but no Contract appeared?

If the Contract is not showing on the Related tab, check that the Flow is active. Go to Setup, type Flows in Quick Find, and verify the High Value Closed Won Contract Flow shows Status = Active.

Also confirm the Opportunity has an Account populated. The Flow creates a Contract using the Opportunity's Account ID. If Account is blank, the Contract creation may fail silently.

Why isn't my Flow creating a Contract on the Related tab?

You have proven that you can design targeted test cases, execute them systematically, and trace a defect back to its declarative root cause. In the next step, you will test how different user profiles change what is visible and editable on the same Opportunity records.

Test with Different User Profiles

In the previous step, you executed a structured test cycle and found a real configuration gap. You now know how to test validation rules and Flow automation against boundary conditions.

One of the biggest differences between Salesforce testing and general application testing is profile-based security. The same Opportunity page can look completely different depending on who is logged in. In this step, you will create a restricted profile and verify that field-level security controls what a user can edit.

In this step, get ready to:

Create a restricted user profile cloned from Standard User.
Assign a test user to the restricted profile.
Verify that field-level security prevents the restricted user from editing a specific field.

Create a new user profile with restricted access

Salesforce profiles control which objects and fields a user can see and edit. You will clone the Standard User profile to create a restricted version, then lock down the Deal Risk Level field so users with that profile can only view it.

Click the gear icon (top-right) and select Setup.
Type Profiles in the Quick Find box on the left.
Click Profiles.
Find Standard User in the list.
Click Clone next to it.
Enter Sales Rep Restricted in the Profile Name field.
Click Save.

You should see the new profile's detail page. The profile now exists, but it has the same field access as Standard User. Next, you will restrict the Deal Risk Level field.

Return to Setup and click Object Manager.
Select Opportunity.
Click Fields and Relationships in the left sidebar.
Click Deal Risk Level in the field list.
Click Set Field-Level Security.
Find Sales Rep Restricted in the profile list.
Check the Read-Only checkbox for that profile.
Click Save.

You should see the field-level security page confirm your changes. The Deal Risk Level field is now read-only for anyone assigned the Sales Rep Restricted profile.

What is field-level security?

Field-level security controls whether a user can see or edit a specific field, independent of page layout. A field can be Visible (user can read and write), Read-Only (user can see but not change), or Hidden (user cannot see it at all). These settings are applied per profile.

Don't see the Read-Only checkbox?

Make sure you clicked Set Field-Level Security (the button), not View Field Accessibility. The Field-Level Security page shows a grid of profiles with Visible and Read-Only columns.

If your new profile does not appear, go back to Profiles in Setup and confirm that Sales Rep Restricted saved successfully.

Help me find the Read-Only checkbox for my custom profile.

Create a test user assigned to the restricted profile

To test how the restricted profile behaves, you need a user account assigned to it. You will create a test user and then log in as that user to see the restrictions in action.

In Setup, type Users in the Quick Find box.
Click Users.
Click New User.
Enter Test in the First Name field.
Enter SalesRep in the Last Name field.
Enter your own email address in the Email field.
Enter testrep@yourorg.testanalyst.dev in the Username field.
Select Salesforce for the User License field.

Why set User License before Profile?

The User License determines which profiles are available in the dropdown. You must select the Salesforce license first, then the profile list will include your custom Sales Rep Restricted profile.

Select Sales Rep Restricted for the Profile field.
Click Save.

You should see the new user's detail page. Salesforce sends a welcome email to set the password, but you do not need to use that for testing.

Use Login As instead of switching accounts

Rather than logging out and back in with the test user's credentials, you can simulate their experience directly. You need to enable this first, then use it from the Users list.

In Setup, type Login Access Policies in Quick Find and select it.
Check the box next to Administrators Can Log in as Any User.
Click Save.
Return to Setup > Users, find Test SalesRep in the list, and click Login in the action column next to their name.

Don't see the Login link?

Confirm that Administrators Can Log in as Any User is enabled under Login Access Policies. Also verify you are using the standard System Administrator profile (not a cloned admin profile that may lack the necessary permissions).

Help me enable Login As for my test user.

Test field-level security as the restricted user

You are now viewing Salesforce as the restricted user. Everything you see reflects the Sales Rep Restricted profile's permissions.

Click the App Launcher (grid icon, top-left) and open the Sales app.
Click the Opportunities tab.
Open an existing Opportunity that has the Deal Risk Level field populated (such as Test Deal Alpha).
Click Edit (or click the pencil icon next to the Deal Risk Level field).

Before you look at the field, predict: what do you expect to happen when you try to change Deal Risk Level as this restricted user?

Verify that the Deal Risk Level field is read-only. You can see the value (e.g. "Medium") but cannot change it.

The field appears greyed out or without an edit control. This confirms that field-level security is enforced per profile.

Why does this matter for testing?

On real Salesforce projects, Test Analysts must verify that sensitive fields are locked down for specific profiles. A misconfigured field-level security setting could let sales reps change risk assessments that only managers should control. This is a category of defect you cannot find without testing as different users.

Now verify that validation rules still fire regardless of the user's profile.

Click New to create a new Opportunity.
Enter any name in the Opportunity Name field.
Set Stage to Closed Won.
Set Amount to 0.
Set Close Date to any future date.
Click Save.

You should see the validation error message at the top of the page: "Amount must be greater than zero for Closed Won opportunities." This confirms that validation rules fire for all users, regardless of profile.

To return to your admin account, click your avatar (top-right) and select Log Out.
Log back in with your System Administrator credentials.

Faster return with Login As

If you used the Login As method, you will see a banner at the top of the page indicating you are logged in as another user. Click Log out on that banner to return to your admin session immediately without re-entering your password.

Can still edit the Deal Risk Level field?

Confirm you are actually logged in as the test user (check the name displayed in the top-right corner). If it still shows your admin name, the Login As did not take effect.

Also verify that the Read-Only checkbox is checked for the Sales Rep Restricted profile under Deal Risk Level's field-level security settings.

Help me figure out why my restricted user can still edit the field.

Secret mission

Create and Test the Missing Validation Rule

You found the defect. Now fix it yourself. Create the missing validation rule for Closed Lost opportunities, then design and execute test cases to verify the fix without breaking anything that already works.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Everything in this project is completely free. Your Salesforce Developer Edition org has no ongoing costs.

Resources you used:

1 Salesforce Developer Edition org (free, no charges).
Custom fields on Opportunity: Deal Risk Level, Close Reason.
Validation rules: Amount_Required_For_Closed_Won, Close_Reason_Required_For_Closed_Lost.
Record-triggered Flow: High Value Closed Won Contract.
Custom profile: Sales Rep Restricted.
Test user: Test SalesRep.
Test Opportunity records and related Contracts.

Keep everything running

No action needed. Choose this if you plan to continue practising Salesforce testing or building on this pipeline.

Your Developer Edition org does not expire as long as you log in at least once every 45 days.
All your custom fields, validation rules, the Flow, and test user remain available for further experimentation.
There are no charges associated with any resource you created.

Pause - I'll come back to this later

Since everything is free, pausing simply means keeping the org alive while clearing out test data so you have a clean slate when you return.

Navigate to the Opportunities tab in the Sales app.
Select all test Opportunity records (Test Deal Alpha, Test Deal Beta, and any others you created during the test cycle).
Click Delete to remove them. Related Contract records created by the Flow will also be deleted.
Log into the org at least once every 45 days to keep it active.

Delete - I don't want to use this again

Remove all project configuration and test data from your org. If you want the org itself to be deactivated, simply stop logging in and Salesforce will deactivate it after 45 days of inactivity.

Delete test Opportunity records: Go to the Opportunities tab, select all test records, and click Delete.
Deactivate the Flow: Go to Setup, type Flows in Quick Find, select Flows, click High Value Closed Won Contract, click Deactivate, then click the dropdown arrow next to Activate and select Delete.
Delete validation rules: Go to Setup, open Object Manager, select Opportunity, click Validation Rules. Click each rule (Amount_Required_For_Closed_Won and Close_Reason_Required_For_Closed_Lost), then click Delete.
Delete custom fields: In Object Manager with Opportunity selected, click Fields and Relationships. Click Deal Risk Level, then click Delete. Repeat for Close Reason.
Deactivate the test user: Go to Setup, type Users in Quick Find, select Users, click Edit next to Test SalesRep, uncheck the Active checkbox, and click Save.
Delete the custom profile: Go to Setup, type Profiles in Quick Find, select Profiles, click Sales Rep Restricted, then click Delete.
To deactivate the org entirely, stop logging in. Salesforce deactivates Developer Edition orgs after 45 days of inactivity.

Nice Work!

You have just completed a full manual test cycle against a live Salesforce Sales Cloud pipeline. You configured the system, designed structured test cases, found a real configuration gap, and documented it exactly as you would on an engagement.

Here is what you accomplished:

Configured a Salesforce Sales Cloud Opportunity pipeline with a custom picklist field, a validation rule, and a record-triggered Flow that auto-creates Contract records for high-value wins.
Designed and executed a structured test cycle covering positive paths, negative paths, boundary conditions, and automation verification. Then identified and documented a configuration defect with root cause analysis pointing to the declarative Setup.
Tested field-level security across different user profiles to verify that permission-based behaviour changes what is visible and editable per profile.
Secret Mission: Created the missing validation rule yourself and ran regression tests to confirm no existing functionality was broken.

Ready to quiz yourself?