0

I'm relatively new to Salesforce development and I'm wondering if someone would be able to provide some insight to a dilemma I'm having.

Backstory: I currently have one component that is used to add a contact to an account. On load, the component tests for a user's ProfileID and displays only relevant information to that department (not every department in my org needs to add a contact birthday for example).

My director would like me to create separate components for each profile so that as a system admin, he can have control while I'm out of town (I'm the only dev), and so that he can have an additional layer of customization over who sees what.

So my question is, is this a valid request? Are there any reasons this would be unfeasible or have any legitimate reasons not to do it this way moving forward? Obviously creating 4-5 components for each profile would be more work on me (which I'm not worried about), I'm moreso worried that having 4-5 components would take up system storage and create unnecessary clutter.

Thanks in advance for any insight.

Improve this question
2
  • What you're describing sounds, to an outsider, like the same functionality that is provided by Salesforce's native CRUD and FLS permissions system. Could you accomplish this need by checking CRUD and FLS at runtime rather than implementing multiple components?
    – David Reed
    Commented Apr 5, 2019 at 16:06
  • Thanks for the response! We have 4-5 different divisions (ticket sales, executive suite sales, sponsorships etc) that all need to be able to add contacts to accounts. However, all divisions have different required fields and some fields are only used by one or two divisions, so our solution was to literally build a custom form with all relevant information based on profileID at runtime. Do you think we'd be able to implement CRUD and FLS permissions into our custom component?
    – Daniel Retaleato
    Commented Apr 5, 2019 at 17:11

1 Answer 1

Reset to default
0

You would normally want to use some combination of Page Layouts, Record Types, and/or Field Level Security (FLS). All of this requires no code at all, and can be as granular as a per-profile basis. You can also further customize FLS by using Permission Sets to add field visibility/editability (but note: you can't remove access this way).

Basically, you can create multiple page layouts, assign them to profiles, specify record types to differentiate records within a profile, and field level security. All of the links above refer to additional links for assigning page layouts, record types, etc.

Improve this answer
2
  • Thanks for the quick response. As of right now, our org is built primarily on custom code, so the framework is all there to get everything done in the background. In your opinion, will all of this be able to be implemented into our custom component?
    – Daniel Retaleato
    Commented Apr 5, 2019 at 16:58
  • @DanielRetaleato Once you start writing your own code, you can do whatever you want. Unfortunately, this usually means losing access to standard functionality. I strongly advise that you consider removing your custom code in favor of standard features as much as possible. However, I do realize that this may not be practical depending on how much needs to be done. It is entirely possible to check field level security, object security, etc in code, but you're making a lot of extra work for yourself. Going back to standard features would probably take less time than more custom code.
    – sfdcfox ♦
    Commented Apr 5, 2019 at 17:17

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .