Communities Project Cheat Sheet
COMMUNITIES IN SF CHEAT SHEET
Shit to check
- what do my users need access to ?
- opps ? > Partner
- reports ? > Probably Partner
- which records do my users need access to ?
- stuff they own or are explicitely linked to ?
- or shit that'll need sharing rules ? > Partner
- How many users and how often do they login ?
> Changes license type, either user based r login based
- How much Files will they store ?
CommunityUsers don't bring loadsa file storage watch out
- How much Data will they store ?
Same, but data in SF isn't super expensive so meh
- Branding ?
Hard to do
- Needs LWC ?
Maybe hard to do depending on class access
- SSO ?
Not hard but always a bother
- Login Pages
Known bug where activating communities may not provision Login elements. If Login page full empty, contact SF support.
Stuff that's hard
Either you're full customer community and there's only Sharing Sets
Or you're in Partner world and you get the worst of every world.
Community Users owning record sis general meh
Sharing records with them based on sharing rules sounds great but is sometimes hard due to the Partner Role structure which just merges with the main one like a big Tick
it's just annoying
Make sure to have a valid sharing diagram, really
Deploying communities is ALWAYS shit
Tools will tell you they ease the process. They lie. There' sonly so many ways to deploy - change sets, API, SFDX. All of them have issues with communities. Maybe you'll get lucky, maybe you won't, who knows.
There's arcane bugs like if your objects have the same beginning of a name Pages won't be carried over because the API deployment truncates the namings
just deploying is HARD.
In general consider it easier to just rebuild the community from scratch in prod rather than deploy. Because that's what you may end up doing.
We're not UI specialists.
Either they go standard, or they hire an Agency. Anything in between they can go fuck off.
DON'T USE ORDERS IN COMMUNITIES
- List Views
remember to change sharing for all list views if any exist before
Also remember to make the list views available for your comm users if they need it
Stuff that's easy
- building pages is nice
- base branding is nice if no custom
- Flows are :100:
- No "separate database", just different view into same system makes shit nice
LOCK DOWN EVERYTHING and then only open up what's necessary
GDPR real people, srsly don't open up shit that doesn't need to be.
Licensing is the main way to fuck up your Comms project
Data access is the second way
Look and feel is the third
Anything else is easy
Awesome new shit
- Record based Audiences mean dynamic pages for users based on criteria
- Flows in comms are so useful they might as well replace the entire thing with that
Weird shit that doesn't matter much
- CMS is a weird offering that kinda only half exists, almost no one at SF has seen it
- Translations can be wonky and still rely on the old Site.Com Builder in the backend but you shouldn't have to go there to edit translations now
- there' s3 different places to look at comm shit:
- the comm builder
- the Site page which is where you see the Guest user access
- the Site Builder page which you can access through Workspace > admin > a small link hidden within one of the pages, that only handles very few things and you can ignore