Idea: More flexibility in definition of criterias

[sfdcschwabe]

For my current idea I have to go a bit further. By the way: During the research for a solution to my problem I became aware of FormulaShare-DX in the first place. I was looking for a solution for dynamic record sharing that adapts the Salesforce standard but allows extensions like using all(!) fields on an object and removing limitations (i.e.: max. 500 sharing rules for one object). So I wanted a solution that could be used in the same way as the Salesforce standard for defining sharing rules, with the same schema: record owner or criteria-based sharing rules, definition of criteria and who the records are shared with.

Am I correct in assuming that FormulaShare does not currently support this, right? My understanding: In FormulaShare it is necessary to specify the ID for a user, role, etc. in a specially created field, so that FS knows that this record is shared with X.

Wouldn't it be more flexible, without using additional fields, to define the criteria (which records should be selected) directly in FS? I chose exactly this approach a few weeks ago in a proprietary development. That was pretty tough for me, since it was the first time I had dealt with Apex releases in this intensity.

From today's point of view, I learned a few things that I didn't consider during my conception phase because Salesforce takes care of it itself 'under the hood':
Changing role assignments must also result in a recalculation of approvals.

About the architecture: Based on this example (https://www.apexhours.com/apex-design-patterns-leveraging-the-flexibility-of-custom-metadata-types/#comment-14665), I was able to outsource the definition of criteria to custom object. Contra: This way of outsourcing the configuration allows only AND links and no OR links. I didn't find a way to develop such a dynamic boolean argument in such a short time. However, I am convinced that, even though there may be some limitations with regard to the nesting of boolean links, it should be possible to use AND and/or OR links. After all, this is what the Salesforce standard offers in the definition of sharing rules. So it must also be possible to adapt this approach!

As you can see on the following screenshots, I lacked the knowledge that custom metadata types are able to use metadata relationships (like in FS) at the beginning of the development, so I decided to use custom objects. From the background to translate the information of technical roles, usernames etc. with an apex trigger into technical Ids.
With the following screenshots I hope the idea behind my description becomes clearer:

Best regards,
Christian

[LawrenceLoz]

Very nice to read your thoughts around this - I've been through some very similar lines of thinking myself!

As a long term goal, I think this would be a good place to get to, though it would be a significant undertaking to do this well and in a way which provides parity with formula fields. There's a few things I think would need to consider:

1. Admins are generally very comfortable with the capabilities of formula fields, so any interface should be familiar and as easy to use and understand as formula fields for people with this skillset
2. It's useful in some circumstances to expose the formula fields themselves on page layouts - this is helpful for users to see who the record is (or will be) shared with
3. Formula fields support referencing fields from multiple levels of parents, as well as nested boolean conditions involving fields from the shared object and various parents - ideally all of this should be possible under a different approach

I feel to deliver this and recommend this as the best approach we'd need to have equivalent capabilities in each of these areas.

There are a few things I've been thinking about and found which are worth considering:

• The branch I'm working on at the moment (https://github.com/LawrenceLoz/FormulaShare-DX/tree/RelatedObjectExtension-8) is intended to address Allow sharing based on contents of objects related across schema #8. With the way this works, it's possible to identify a parent object related to the shared object and pick a field on this which controls sharing. For some use cases this means formula fields can be avoided completely. If conditional logic is exposed, it may make sense to allow this to be defined separately for each object involved in a relationship which could address some of the other capabilities for formula fields. (as an aside, it would be great to get your input to review this work once it's getting towards completion)
• There's an open source project which provides a mechanism to allow defining and assessing conditions (see the "Expression Builder LWC" section here https://unofficialsf.com/formula-builder-expression-builder-and-formula-engine/). I've not had a chance to review in detail but this might be a helpful building block in a solution to 1 and 3
• We could potentially address 2 above with a generic LWC component which can be added on any page. This could actually be better than relying on the contents of a formula field as it can potentially show the sharing which will be applied as well as that which has already been applied. There could also be a button to reassess sharing on demand and perhaps other nice features

So yeah I think it's a great idea, but may be quite a big task to get there. The core of FormulaShare is pretty involved and this would touch some quite fundamental elements - with the nature of the app I think it's best we're super cautious about how these kind of core changes are introduced as the risk is very high if major issues are introduced in production orgs, but definitely supportive of this as an approach and something to work towards.

Great to see our thinking is aligned!