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 absed on sharing rules soudns great but is sometimes hard due to the Partner Role structure which just merges witht he 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. Maybe you'll get lucky, maybe you won't, hwo 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 dpeloyment truncates the namings
jsut deploying is HARD.

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

Consiedrations
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 adn feel is the third
Anything else is easy

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

Weird shit that doesn't amtter much
- CMS is a weird offering that kinda only half exists, almost no one at SF has seen it
- Translations can eb wonky and still rely on teh old Site.Com Builder in the backend but you shouldn't ahve to go there to edit translations now
- there' s3 different places to look at comm shit:
- the comm buidler
- the Site page which ios where yous ete Guest user access
- the Site Buidler page qhich youa ccess through Workspace > admin > a small link hidden within one of the pages, that only handles very few things and you can ignore