Missing Lightning Platform tooling (Flexipage, Lighting Flows, Lightning Data Service)

[tsalb]

A big part of a modern Salesforce Developer is to also leverage the platform when it makes sense, so there are a couple topics I'm not quite sure how to slot in, but something like a Learn the Lightning Platform block:

• Flexipage and component visibility tooling.
• Custom Permissions tooling (Apex, Flexipage).
• Lightning Platform Features:
  • Process Builder
    • When to use over triggers (email alerts, notifications, PB only actions).
    • How to separate concerns when mixing automations.
  • Lightning Data Service
    • When to use LDS vs Apex.
  • Lightning Flows
    • How to build reusable apex for schedulable flows, for admins (invocable etc).
    • How to build reusable wizard with screen flows backed by LWC or Apex.

I agree it's hard to distill these concepts into a single one-liner but it might help to just list them out first before a round of word-smithing!

[ChuckJonas]

Seems like some of this is already represented...

I'm not sure it makes sense to split out lightning vs classic... Lightning is the new default so we should just focus on that. While I actually still spend most my time in classic, I think those days are numbered. Because I'm not an expert many aspects of lightning, I'm definitely looking to others for help here.

Flow is under configuration (I consider Process Builder to be "flow" as well; but maybe we update the node to Flow/Process Builder). I've avoided going deep into the specific types of flow because that level of detail is probably beyond the scope of this "30ft view". At some point it would be cool to break out "sub maps" for topics could benefit from a more granular scope.

• Flexipage should probably just be added along side or next to customize -> layouts
• Lightning Data Service should probably be off of UI -> Javascript

Some of these ideas might be added to Design. Maybe could be summed up as "Code vs Configuration"...

Thoughts?

[ChuckJonas]

I'm still trying to figure out the best way to make this a collaborative effort, but for now I think giving people the ability to comment on the diagram might be a good short term solution

https://www.lucidchart.com/invitations/accept/00b19a2a-e50c-4598-a1e3-7000b21d88f4

[tsalb]

For some context, my time has been about 7:3 (years to classic:lightning) so my enhanced emphasis on that anything Lightning related.

Basically, it would be a disservice to a modern Salesforce Developer working in Lightning to place so much emphasis in Apex when LDS can do most of the use cases simple CRUD can do. I see this obstacle quite often in new developers transitioning to Lightning/LWC in that something OOTB (LDS) can do 10x more easily than Apex.

In other words, we could even have Lightning Data Service be a box in itself between Apex and Building UIs because LDS itself is so, so much more. LDS itself (specifically uiApi) is the fundamental building block of all native CRUD/DML. There are, now, hooks for us devs to hook into them. Let me spend some time noodling and maybe I can help provide an outline of what the Lightning Data Service block and its respective tree would look like.

My original callout is to place more emphasis on some of the trees you've already established:

Layouts => Record Types Flexipages => Component Visibility Flexipages => Dynamic Forms (this is the future) Lightning Data Service => [something]

[ChuckJonas]

interesting take...

I think part of the challenge with this is drawing the line of what is considered "admin" and what is considered "developer" (salesforce has intentionally blurred this line in the past). It almost feels if we go too heavily into the details of the configuration, then "Salesforce Developer" really becomes a superset of "Salesforce Admin".

And while developers do need to understand most the available configuration points of the platform, my initial thought was to center around traditional developer activities (+ visual code). Apex, LWC, Aura, Flow, Evergreen*, Heroku, Platform API's, etc

That's not to say I'm opposed to including everything, if we can figure out how to do it in a clean way (as I mentioned above, I'm personally behind on lightning so I will be looking heavily to others).

It would be cool to just have a single massive chart and progress from admin -> developer -> TA as you go down. It might need to become less linear to reflect that to be a dev you don't need to have the full admin skillset. Lot's of possibilities! The challenge in doing so it we have to draw hard boxes around concepts that have a lot of fluidity and cross over.

[tsalb]

Ah, my discussion here is not to derail your original vision, rather, add some flavor to it as a TA/Dev who has worked exclusively in lightning and see for myself a lot of tooling that has replaced my need for the traditional developer approaches.

IMO, a salesforce dev has always been a superset of an admin - and should strive to learn all the declarative tooling just so they know what OOTB tools they can bend with a developer’s skillset and approach.

So, I went into this repo with that assumption. Take the following examples (that I have hit in the real world):

• Using Screen Flows with a backing custom component that stores state between screens which deprecates the need for a traditional wizard UI written completely from scratch. Not possible unless the dev has explored the nuances of screen flows.

• Using flexipage and component visibility as your SPA container rather than a real spa with a complicated tree hierarchy and dynamic visibility templating system.

• Leveraging scheduled flows instead of schedulable interface for kicking off batch apex.

As it stands, I think your linear diagram works but my original concern was the amount of real estate dedicated to Apex could lead a new-ish dev to over invest there only to learn there is a much easier (and modern) way to do certain operations in Lightning / LWC.

Feel free to pick my brain on Lightning to see where I can help. I wrote a big portion of the incoming LWC superbadge and I helped write a small part of the incoming JS Dev 1 cert.

Luckily, I don’t work for Salesforce, so I’m happy to chat candidly about Lightning’s pros and cons.

[ChuckJonas]

Yea, my company tends to operate on the other end of the spectrum. About a third of the time I spend working "on salesforce" is building react/redux SPA. These are complicated applications that benefit immensely from not using "out of the box" solutions. Another third is building out API or integrating with other API.

The final third is more the stuff you are discussing above. For this, I'm definitely one of those people who could benefit from knowing more about how I can leverage the latest and greatest OOTB in my designs (once my clients finally make it over to lightning).

I would be super interested in seeing how you would build out the Lightning platform graph. If you wanted to give it a shot (in your diagramming tool of choice), then I can definitely take that and try to incorporate it.

I'll make sure to give you contributor credit!

[tsalb]

Will do! I'll post back here when I get a chance to tackle it this week.

[tsalb]

Here's an initial draft that I finally got around to. I figured providing you the actual slides won't be of much value but let me know if you want them regardless.

[tsalb]

@ChuckJonas - forgot about this and just sending you a quick ping

[ChuckJonas]

Hey @tsalb

Thanks for following up! It's on my todo list to get to this sooner than later...

I definitely will be incorporating this in some way... I'm still messing around how to organize the chart and if it's possible to bring in the "full breadth" of "salesforce admin" without making it a giant mess.

I'm thinking maybe having different branches or paths...

The challenge creating something comprehensive but still gives clear direction to someone new to the platform