Tips & Tricks: Choosing the right logic block security option
One of the most misunderstood and misued platform features is logic block security. Here’s a quick guide to help you pick the right setting the first time.
The golden rule: default to Public
When in doubt, use Public. Don’t reach for Public-Secured unless you have a specific, well-thought-out reason to bypass security. Blindly setting something to Public-Secured can introduce unintended access risks - always consult your security point of contact if you’re unsure.
Quick decision guide
Use the flowchart above, or follow this mental checklist:
- Private - Only needed when your logic block should never be called outside its own product family. It inherits security from whatever calls it, so no special action security setup is needed.
- Public - Your go-to for logic blocks called across families, modules, or used as common blocks. Row security applies per user, so make sure permissions exist for every table the logic block touches. Logic blocks that populate flat data tables for reports must be Public.
- Public-Secured - Reserved for transactions or validations that genuinely need to update fields the user can’t normally access (like workflow-restricted fields). You’ll need action security configured, and you should have a clear justification for bypassing standard security.
A few things to watch for
- Adding a new Public logic block to an existing feature may require adding row security permissions - don’t forget to check this with your security contact.
- Common logic blocks called by external sources should be Public-Secured with a specific Security Group. Common logic blocks shared across internal modules should be Public without a Security Group.
- The security option on your calling logic block determines how all downstream (processing) logic blocks behave - even if those downstream blocks are configured differently.
Nextworld Help links:
Logic block security options
Logic block security option best practices