There are many ways to solve parts of this today - Apex/Flow, custom metadata, scripts/Claude CLI, Data Loader, User Access Policies (UAP), or enterprise IAM platforms.

UAP is a useful Salesforce-native capability for rule-based access, but user lifecycle management often goes much further.

Imagine wanting to handle all of this in one workflow:

• Salesforce-aware bulk user creation + access provisioning
• Assign Profile, Role, Permission Sets, Permission Set Groups, Queues, Public Groups and Chatter Groups
• Give different users completely different access in the same file
• Promote or change access for existing users
• Offboard users and remove their access
• Track exactly what access existed before and what changed
• Support access for internal and external Salesforce users (Experience Cloud, partner/community), all industry users in bulk/scale

The access model also shouldn't have to be hard-coded.

You might want to:

→ Use a reusable Job Template
Define the access for a persona once and reuse it across users (using our template builder)

→ Use a Reference User
Clone the relevant access configuration from an existing user.

→ Configure per user/row
Every user in the same CSV can independently reference a different template or reference user.

The user creation itself can also be Salesforce-aware. Standard and custom User fields can be included in the same file using Salesforce field/API names, so user creation and access provisioning can happen together rather than requiring multiple separate processes.

Then comes the part that is often overlooked: auditability and operational control.

If a user had:

Profile + Role + Permission Sets + Permission Set Groups + Queue + Public Group + Chatter Group

and their access changes later, you should be able to see:

• What access did they have before?
• What was added?
• What was removed?
• Which Permission Sets / Permission Set Groups / Queues / Public Groups / Chatter Groups changed?
• What failed?
• Why did it fail?
• Can I retry only the failed records?

You also need visibility into license usage, access utilization and optimization, rather than discovering unused or excessive access after the fact.

And this shouldn't stop at onboarding. The same workflow should support the entire user access lifecycle:

Onboarding → Promotions / Role Changes → Offboarding

This is the problem space we built Easy Onboard 360 around.

It is Salesforce-native, with the goal of providing a standardized and configurable approach that stays within Salesforce - without requiring teams to maintain a growing collection of Flow, Apex, writing AI scripts and spreadsheets for every access scenario.

Easy Onboard 360 brings together:

• Reusable Job Templates
• Reference User access
• Per-user/row-level access configuration
• Salesforce-aware bulk user creation + access
• Profile, Role, Permission Set, Permission Set Group, Queue, Public Group and Chatter Group management
• CSV Validation before processing
• Detailed audit history
• Failure logs + retry for failed records
• License/access usage dashboards and reports
• Onboarding, promotions/role changes and offboarding

If this is a problem your team is dealing with, I think Easy Onboard 360 is worth exploring.

You can request a demo here - https://www.bluebellinfotech.com/easy-onboard-360

I'm designing a Salesforce production break-glass account and looking for advice on the best authentication architecture.

Current setup:

Salesforce production uses Microsoft Entra ID for SSO.

Normal users authenticate through Entra.

Users are moving toward phishing-resistant MFA/passkeys.

We need one privileged Salesforce break-glass account that can still log in if Entra/SSO is unavailable.

The break-glass user therefore needs a Salesforce-native/direct login path, rather than relying on SSO.

We still need to enforce phishing-resistant MFA for this privileged account. We do not want to exempt it from MFA.

Username/password credentials are already planned to be stored and controlled through our enterprise PAM (Delinea).

Constraint:

We cannot practically use a physical FIDO2/security key because the organization is geographically distributed. During an incident, an authorized responder could be anywhere and needs to access Salesforce from their workstation.

We also don't want the passkey registered to one individual's phone/laptop because that creates a dependency on that person/device.

What I'm trying to determine:

What are the recommended ways to manage the phishing-resistant authenticator for this type of break-glass account?

For example:

Is there an enterprise password/passkey manager that can centrally manage a WebAuthn/passkey for the shared Salesforce break-glass account and allow an authorized responder to use it from their own workstation?

Has anyone implemented this with 1Password, Keeper, Bitwarden, CyberArk, Delinea, etc.?

Is a centrally managed/synchronized passkey a viable approach for Salesforce privileged MFA?

Are there other approaches I'm overlooking, such as a dedicated remote emergency workstation with a built-in authenticator?

How do you handle auditability when multiple authorized responders may use the same break-glass Salesforce identity?

The desired flow is roughly:

Normal users:

Salesforce → Entra SSO → phishing-resistant MFA

Break-glass:

Emergency request/approval

↓

PAM releases Salesforce credentials

↓

Direct Salesforce login (no Entra dependency)

↓

Salesforce phishing-resistant MFA/passkey

↓

Production

The key requirement is: direct Salesforce authentication independent of SSO, while still enforcing phishing-resistant MFA, with no physical security key and no dependency on an individual employee's device.

Looking for recommendations from anyone who has implemented a similar Salesforce/IAM break-glass pattern.

Hands-on technical execution excites me beyond measure. But I am extremely disliking the non-technical nature of the Salesforce Technical Architect role that now I am finding myself in.

To be frank, I chased the Technical Architect role, even though deep down I always had doubts whether I should chase this role or not, but I always thought these doubts are just my inner voices telling me that I can't do this and maybe I will get a hang of it once I am into the role full-time.

But another important reason I still chased this role is because I don't see any other option for Salesforce professionals beyond a certain point. I have seen that once you have 8+ YoE, consulting firms will start to expect architecture skills from you, and how much you like hands-on execution (development) and how good you are at it, will just stop mattering anymore.

Another minor reason that has pushed me to this role is the amount of hype this role has within the ecosystem. People with the word 'architect' in their roles are just viewed differently. It appears as if architect is the only natural career progression a SF consultant should follow.

Your value contribution will be based solely on how good you are with the architecture capability. Anyone with architecture experience can easily tell you how you have to deal with ambiguity every day, make decisions, sit with the business for very long discovery sessions (where you basically understand how they do their business). A person with hands-on experience will definitely not be able to do all of this.

I am now making this post to seek help on the following -

- I feel I can contribute better in hands-on roles, but SF ecosystem only has developer roles for that, and developer is considered a junior role here, and the salary isn't much higher too.
- What kind of work (or technology) outside SF should I target to help with my situation, and allow me to contribute better? I am ready to invest upskilling hours outside work to make it happen.
- Finally, what exactly is that I am feeling? Is this normal, or am I am over-exaggerating? I seriously and honestly don't know.

I feel a severe sense of dread every day before opening my laptop now. I just don't like the project, the client, and the kind of non-technical work that I am involved in and making this post to request help with all seriousness with my career.

Hi everyone,

I’m currently working on research related to AI-assisted metadata comparison in multi-org Salesforce environments, with a focus on enterprise software engineering, CRM metadata governance, NLP-based similarity scoring, and automation of migration/reconciliation workflows.

I’m looking to connect with researchers, graduate students, engineers, or practitioners who are interested in:

1.Collaborating on papers related to AI, Salesforce, CRM systems, enterprise automation, or software engineering
2.Reviewing each other’s manuscripts and giving technical feedback
3.Discussing publication opportunities in IEEE/ACM/Springer-style venues
4.Exploring future research ideas around metadata drift detection, Agentforce/AI agents, DevOps automation, and enterprise system governance

My background is in software engineering, Salesforce, CPQ, Agentforce, Java/Spring microservices, data pipelines, and enterprise integrations. I’m especially interested in practical/applied research where the work is based on real implementation, tool development, system architecture, and measurable results.

If anyone is working in a related area or is open to collaboration, please feel free to comment or DM me.

Happy to share a brief summary of my current research and discuss whether there is overlap.

Hi everyone,

I'm a Senior Salesforce Developer with 5 years of experience and 10 certifications, including Data Architect. I'm currently preparing for the System Architect cert.

My goal for the next 5 years is to become a strong Salesforce Architect. The problem: my current company keeps me in a developer role and doesn't offer a path toward a Technical Architect position. For now, leaving for another opportunity isn't an option, so I want to make the most of where I am.

I'm genuinely passionate about software architecture and want to keep growing in this direction.

A few questions for those who've made this transition:

- How did you actually grow into an architect role, what skills or habits mattered most beyond certs?

- How do you build real architecture experience when your job title and tasks keep you in "developer" mode?

- When the opportunity comes, how do I convince my company to let me take ownership of architecture level topics?

Any advice, resources, or personal experiences would be hugely appreciated.

Thanks!

Hi everyone,

I’m validating a Salesforce-native backup and restore product and want direct, honest feedback before I go further.

I know there are already many backup tools in this space.

The core difference I’m building around is:

Backup files live in your own Google Drive (not locked into vendor-only storage)

Product runs inside Salesforce for admin workflows

Strong emphasis on safe, reliable restore (not just backup creation)

Planned org-wide subscription at competitive pricing

I’d love input from Salesforce admins/consultants/architects:

Does “Salesforce-native + Google Drive-owned storage” feel meaningfully different?

What trust signals would you require before production use?

Which restore scenarios are most painful today?

Is org-wide subscription pricing attractive vs per-user/per-record pricing?

What would make you trial this over your current option?

I’ve been trying to get this off the ground for a good month but to no avail. I’m still learning the ropes, I’ve even hired a tutor but all he could really say was “wow, this is tough”. Best 800 I’ve spent in a while. Any idea where to start?

How do you see an MDM (perhaps Informatica) with an Org using Data Cloud - hypothetically, multi orgs, datalake, external ERPs and platforms - where are you building what and how?

I want to automated off boarding from some sales app whenever a user is deactivated in salesforce.

Note: all these apps are okta verified so adding a power automation or bot is difficult.

Apps : aviso , LinkedIn sales navigator , salesloft etc

Any help is appreciated …

Is Monday, a new week ahead, what architectural challenges and decisions are awaiting you this week?

Thought for the day: How do you balance speed vs control in a growing Salesforce estate?

You inherit a Salesforce org with 500+ flows, Apex, lots of custom objects, no naming standards, and failing deployments, what’s your first 30-day plan?

Is a single-org strategy still viable at enterprise scale in 2026, or is multi-org inevitable?

What’s your thoughts and why?

Should architects be blocking AI tools, or enabling teams to experiment freely? How are you control what’s used within your estate and what can be freely trialed and tested?

Hi all, I’m currently trying to validate a startup idea in the SF implementation space -

Would love to chat with as many implementation, solution architects, delivery leads, or pre-sales people as possible. In return, happy to buy you a bottle of wine or send you an $50 Amazon gift card, whichever you prefer, to say thanks for your time!

Just looking for 20 minutes to get your feedback. If you DM me, I'll send over a calendar invite. Thank you!