The S-Object Blog

If you're managing a Salesforce org with more than 50 users, you know the pain. A new employee joins — you need to create their account, assign the right profile, add them to permission sets, set their role, and configure their groups. Multiply that by every onboarding, every department change, every offboarding, and you're spending hours every week on pure administration.

The Problem with Manual User Management

Salesforce's native user management interface is built for individual records. It works fine when you have 10 users. At 100 or 1,000, it becomes a bottleneck. Admins resort to spreadsheets, manual checklists, and error-prone repetition.

How User Manager Changes This

User Manager is built around one core idea: what takes 30 clicks should take 1. With User Manager you can:

• Upload a CSV to create or update hundreds of users at once
• Assign permission sets across an entire team in seconds
• Deactivate departing employees and reassign their records in one workflow
• Monitor license usage so you're never paying for seats you don't need

Real Time Savings

Admins using User Manager typically report saving 3-5 hours per week on user administration alone. For a team with frequent onboarding, that adds up to days recovered every month.

User Manager is available now on Salesforce AppExchange — free to install and 100% native to your org.

We've worked inside hundreds of Salesforce orgs — startups, mid-market companies, and global enterprises. And while every org is different, the same architectural mistakes show up again and again. Here are the five we see most often.

1. Over-relying on Profiles Instead of Permission Sets

Profiles were the original way to manage access in Salesforce. But they're rigid — one profile per user, and changes affect everyone on that profile. Permission sets are far more flexible, letting you layer specific permissions on top of a base profile. Salesforce itself has been pushing this direction for years.

2. Building Logic in Workflows Instead of Flow

Workflow Rules are being retired by Salesforce. Orgs that haven't migrated to Flow are accumulating technical debt that will eventually force an expensive migration under pressure.

3. Ignoring Governor Limits Until It's Too Late

Salesforce enforces strict limits on SOQL queries, DML statements, and heap size. Orgs that don't design with these in mind hit walls as data volumes grow — and fixing governor limit issues in production is painful.

4. No Data Model Documentation

Custom objects multiply over time. Without documentation, new admins and developers spend weeks reverse-engineering what fields mean and how objects relate. This slows every future project.

5. Treating Every Problem as a Customization Problem

Salesforce has native solutions for most common business needs. Over-customization makes orgs brittle, hard to upgrade, and expensive to maintain. The best architects ask "what does Salesforce already do here?" before writing a single line of Apex.

Salesforce is widely used across the GCC, but many implementations underestimate the localization work required to make the platform truly effective for Arabic-speaking teams. Having deployed Salesforce for organizations in Saudi Arabia, UAE, and beyond, here's what we've learned.

RTL Language Support

Salesforce supports Arabic and right-to-left text rendering, but it requires configuration. Field labels, page layouts, and custom components all need to be reviewed for RTL compatibility. Some Lightning components don't behave correctly in RTL by default and need custom CSS overrides.

Data Residency Considerations

Some organizations in the region have requirements around where their data is stored. Salesforce's Hyperforce infrastructure now offers local data residency options in the Middle East — this should be evaluated early in any engagement, not after go-live.

Hijri Calendar

Many business processes in the region use the Hijri (Islamic) calendar alongside Gregorian. Salesforce doesn't natively support Hijri dates, so custom solutions are required if your processes depend on them.

Training in Arabic

User adoption is the single biggest predictor of Salesforce success. If your end users speak Arabic, they need training materials, documentation, and support in Arabic. We provide all of this — it's one of the reasons clients in the region choose S-Object Solutions.

Salesforce has been signaling for years that profiles are on their way out. The platform's direction is clearly toward permission sets and permission set groups. So where does that leave orgs that have built their entire access model on profiles?

What Profiles Still Do

Profiles aren't gone yet. They still control object-level defaults, page layouts, record types, login hours, and IP restrictions. You still need a profile for every user — but the goal is to make it as minimal as possible and layer everything else through permission sets.

What Permission Sets Do Better

• Flexibility — assign multiple permission sets to one user without creating a new profile
• Reusability — one permission set can be shared across many different user types
• Auditability — easier to see exactly what access a specific user has
• Future-proofing — Salesforce is investing in permission sets, not profiles

The Migration Approach

The cleanest migration strategy is to create a minimal "base" profile that covers only the essentials, then recreate all your permission-specific access as permission sets. User Manager makes this process significantly faster — you can reassign permission sets across entire user groups in minutes rather than hours.

Data migration is consistently the phase that causes the most project delays. Teams underestimate the complexity of cleaning legacy data, mapping it to Salesforce's data model, and validating it post-migration. Here's the approach we use on every engagement.

Phase 1: Data Audit

Before touching a single record, we audit the source data. How much of it is actually needed? What's the quality like? Duplicate accounts, incomplete contacts, and orphaned records are all far cheaper to deal with before migration than after.

Phase 2: Data Mapping

Every field in the source system needs to map to a field in Salesforce — or be consciously excluded. This mapping document becomes the single source of truth for the migration and prevents surprises during load.

Phase 3: Test Migration

We always run at least two test migrations into a sandbox before the production cutover. This surfaces data quality issues, reveals mapping gaps, and lets the business validate that records look correct in Salesforce.

Phase 4: Cutover Planning

The go-live migration needs a precise plan: when does the source system freeze, how long does the migration take, what's the rollback plan, and who signs off on validation. A good cutover plan makes go-live boring — which is exactly what you want.

Salesforce licenses aren't cheap. A single Sales Cloud Enterprise license can cost $150/month or more. Yet most orgs we audit are paying for licenses that haven't been used in months — sometimes years. Here's how to find and reclaim them.

Step 1: Pull a Login History Report

In Salesforce, go to Reports → create a report on User Login History. Filter for users who haven't logged in within the last 90 days. This is your starting point — but don't deactivate anyone yet.

Step 2: Cross-Reference with HR

Some inactive users are on leave, not departed. Always confirm with HR before deactivating anyone. The last thing you want is to lock out someone who's coming back from parental leave.

Step 3: Review License Types

Are all your users on the right license type? Many orgs have users on full Salesforce licenses who only need read access — they could be on much cheaper Salesforce Platform or CRM Analytics licenses instead.

Step 4: Act on What You Find

This is where User Manager becomes invaluable. Once you've identified users to deactivate or downgrade, you can process them in bulk — uploading a CSV and making changes across hundreds of users in a single operation rather than editing records one by one.

Most orgs we work with recover 10-20% of their license costs after a thorough audit. For a 100-user org, that's often thousands of dollars per year.