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 storag,e 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 wher activating communities may not provision Login elements. If Login page full empty, contact SF support.

Stuff that's hard
- Sharing
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 absedbased on sharing rules soudnssounds great but is sometimes hard due to the Partner Role structure which just merges withtwith hethe main one like a big Tick
it's just annoying
Make sure to have a valid sharing diagram, really
- Deploying
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 communiuties.communities. Maybe you'll get lucky, maybe you won't, hwowho knows.
There's arcane bugs like if your objects have the same beginning of a name PAgesPages won't be carried over because the API dpeloymentdeployment truncates the namings
jsutjust deploying is HARD.

In general consierconsider it easier to just rebuild the community from scratch in prod rather than deploy. BecauyseBecause that's what you may end up doing.
- Branding
We're not UI specialisets.specialists.
EitehrEither they go standard, roor they hire na Agency. AnythingninAnything in between they can go fuck off.
- ORDERS
ORDERS SUCK
THEY DO
DON'T USE ORDERS IN COMMUNITIES
PERIOD
- List Views
remember tochangeto 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", jsutjust different view into same sytemsystem makes shit nice

ConsiedrationsConsiderations
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 adnand feel is the third
Anything else is easy

Awesome new shit
- Record based AudiancesAudiences mean dynamic pages for users based on criteria
- Flows in comms are so useful they might as well repplacereplace the entire thing with that

Weird shit that doesn't amttermatter much
- CMS is a weird offering that kinda only half exists, almost no one at SF has seen it
- Translations can ebbe wonky and still rely on tehthe old Site.Com Builder in the backend but you shouldn't ahvehave to go there to edit translations now
- there' s3 different places to look at comm shit:
- the comm buidlerbuilder
- the Site page which iosis where yousyou etesee the Guest user access
- the Site BuidlerBuilder page qhichwhich youayou ccesscan access through Workspace > admin > a small link hidden within one of the pages, that only handles very few things and you can ignore