Hi @Edwin_Melgar,
Thank you for your question! I will include information about what I've seen so far when working with different customers.
The solutions configured by users include:
- Restrict creation of new projects during specific periods (for example, FY end)
- Restrict expense submissions above a certain threshold without approval
- Prevent users from assigning tasks to themselves in high-priority projects
- Restrict edits to task timelines once a project reaches a defined status
- Limit various API actions vs UI actions
In general our customers have mentioned that these solutions require a low effort. It can get complicated when using multiple wildcards or nested conditions, but as long as everything is well planned out before the business rule is activated, you should be ok. Testing in a Preview or Sandbox environment is recommended to ensure the rule is running smoothly.
A few things to consider:
- Business rules do not override access level restrictions (for example, if a user does not have permission to edit an object, a business rule that allows edits would not allow this specific user to edit that object because their access level is preventing it)
- If you create multiple business rules for the same object, the system will respect all of them but not in a specific order
- Error messages should be concise and constructive; in some cases, it might even be a good idea to provide a link with more information to help avoid confusion in the error message itself
Overall, our customers have been liking business rules and been successful in implementing custom solutions for their teams.
- Monica
