OrgCheck
OrgCheck copied to clipboard
SalesforceLabs
Include more Rules in Automation from Ruben's scanner
Idea from @rubenhalman
Your Flow scanner would definitely be included in OrgCheck.
Let's work together and first see if out of the box, you have enough information from what I get from Flows to run your 7 (or more) rules.
From Workbench:
/services/data/v53.0/tooling/query?q=SELECT+Id,+FullName,+DefinitionId,+MasterLabel,+VersionNumber,+Metadata,+Status,+Description,+ProcessType++FROM+Flow+WHERE+Id+=+'3013V0000008jiD'
Results:
{
"size" : 1,
"totalSize" : 1,
"done" : true,
"queryLocator" : null,
"entityTypeName" : "Flow",
"records" : [ {
"attributes" : {
"type" : "Flow",
"url" : "/services/data/v53.0/tooling/sobjects/Flow/3013V0000008jiDQAQ"
},
"Id" : "3013V0000008jiDQAQ",
"FullName" : "orgcheck__test3",
"DefinitionId" : "3003V0000004NFwQAM",
"MasterLabel" : "test3",
"VersionNumber" : 1,
"Metadata" : {
"actionCalls" : [ ],
"apexPluginCalls" : [ ],
"apiVersion" : 51.0,
"assignments" : [ ],
"choices" : [ ],
"collectionProcessors" : [ ],
"constants" : [ ],
"decisions" : [ ],
"description" : null,
"dynamicChoiceSets" : [ ],
"formulas" : [ ],
"interviewLabel" : "test {!$Flow.CurrentDateTime}",
"isAdditionalPermissionRequiredToRun" : null,
"isOverridable" : null,
"isTemplate" : null,
"label" : "test3",
"loops" : [ ],
"orchestratedStages" : [ ],
"overriddenFlow" : null,
"processMetadataValues" : [ {
"name" : "BuilderType",
"value" : {
"apexValue" : null,
"booleanValue" : null,
"dateTimeValue" : null,
"dateValue" : null,
"elementReference" : null,
"numberValue" : null,
"sobjectValue" : null,
"stringValue" : "LightningFlowBuilder"
}
}, {
"name" : "CanvasMode",
"value" : {
"apexValue" : null,
"booleanValue" : null,
"dateTimeValue" : null,
"dateValue" : null,
"elementReference" : null,
"numberValue" : null,
"sobjectValue" : null,
"stringValue" : "AUTO_LAYOUT_CANVAS"
}
}, {
"name" : "OriginBuilderType",
"value" : {
"apexValue" : null,
"booleanValue" : null,
"dateTimeValue" : null,
"dateValue" : null,
"elementReference" : null,
"numberValue" : null,
"sobjectValue" : null,
"stringValue" : "LightningFlowBuilder"
}
} ],
"processType" : "Flow",
"recordCreates" : [ ],
"recordDeletes" : [ ],
"recordLookups" : [ ],
"recordRollbacks" : [ ],
"recordUpdates" : [ ],
"runInMode" : null,
"screens" : [ {
"allowBack" : true,
"allowFinish" : true,
"allowPause" : true,
"backButtonLabel" : null,
"connector" : null,
"description" : null,
"elementSubtype" : null,
"fields" : [ ],
"helpText" : null,
"label" : "test",
"locationX" : 176,
"locationY" : 158,
"name" : "test",
"nextOrFinishButtonLabel" : null,
"pauseButtonLabel" : null,
"pausedText" : null,
"processMetadataValues" : [ ],
"rules" : [ ],
"showFooter" : true,
"showHeader" : true
} ],
"sourceTemplate" : null,
"start" : {
"connector" : {
"isGoTo" : null,
"processMetadataValues" : [ ],
"targetReference" : "test"
},
"description" : null,
"doesRequireRecordChangedToMeetCriteria" : null,
"elementSubtype" : null,
"filterLogic" : null,
"filters" : [ ],
"label" : null,
"locationX" : 50,
"locationY" : 0,
"name" : null,
"object" : null,
"objectContainer" : null,
"processMetadataValues" : [ ],
"recordTriggerType" : null,
"schedule" : null,
"scheduledPaths" : [ ],
"triggerType" : null
},
"startElementReference" : null,
"status" : "Draft",
"steps" : [ ],
"subflows" : [ ],
"textTemplates" : [ ],
"urls" : null,
"variables" : [ ],
"waits" : [ ]
},
"Status" : "Draft",
"Description" : null,
"ProcessType" : "Flow"
} ]
}
Hey @VinceFINET & @forcePanda, I hope you are well.
Sorry for my slow response, but I have looked at the metadata we get via the tooling API and we get the necessary information to run process using the core rule module of the flow scanner.
It will be some work on my end to adapt the core module to support the format, which I hope to finalize for one or a few rules. The next challenge will be to find a way to integrate this module into your project. As a first step it can be maybe be as simple as to compile the typescript to JS and upload a static Javascript resource in SF.
Is this something we can look at together, or do you have any thoughts on how to implement this? We should already be able to try setting up he GetRules() from the core module.
https://github.com/Force-Config-Control/lightning-flow-scanner-core
Do you have a description of each rule you implement? And for each one how to you compute the score based of he information that you have in the tooling api or metadata or api!?!
@VinceFINET Let me know if this answers your questions:
DML statements in a loop To avoid hitting Apex governor limits, we recommend grouping all of your database changes together at the end of the flow, whether those changes create, update, or delete records.
Source code: DMLStatementInLoop
Duplicate DML operations If the flow commits changes to the database or performs actions between two screens, don't let users navigate back between screen. Otherwise, the flow may perform duplicate database operations.
Source code: DuplicateDMLOperationsByNavigation
Hardcoded Ids IDs are org-specific, so don’t hard-code IDs. Instead, pass them into variables when the flow starts. You can do so, for example, by using merge fields in URL parameters or by using a Get Records element.
Source code: HardcodedIds
Missing flow description Descriptions are useful for documentation purposes. It is recommended to provide information about where it is used and what it will do.
Source code: MissingFlowDescription
Missing error handlers Sometimes a flow doesn’t perform an operation that you configured it to do. By default, the flow shows an error message to the user and emails the admin who created the flow. However, you can control that behavior.
Source code: MissingFaultPath
Missing null handlers If a Get Records operation does not find any data it will return null. Use a decision element on the operation result variable to validate that the result is not null.
Source code: MissingNullHandler
Unconnected elements Removing unconnected elements which are not being used by the Flow makes your Flow more efficient and maintainable.
Source code: UnconnectedElements
Unused variables Removing unconnected variables which are not being used by the Flow makes your Flow more efficient and maintainable.
Source code: UnusedVariables
The core module is also integrated with the VSCode extension that I have shown you. Using the getrules method you can get info on all the rules currently included, which I should have probably included in the description!
Nice. Couple of things here.
1- currently OrgCheck’s main code is written in JavaScript in a static resource. But I have in mind to turn this code into typescript modules in order to reuse the code in a sfdx CLI plugin version.
2- I made some tests in a dummy project and you can have a typescript project with a process that converse (locally on your vscode or it could be done via gitactions I wonder) the code into whatever version of JavaScript. At the end the JavaScript version could be inserted in the salesforce app as a static resource. At this point it is more about building the app rather than modifying directly manually part of the app. Which is what I am doing right now in the current version.
3- in orgcheck I show a tabular view of the flows with rows and columns. Italy this point we will need to check if having a column for each rule or one unique column is better visually.
4- as I am working potentially with a large amount of flows in an org we will need to be careful with the way we compute the output of your rule engine. Is it possible to handle a large number of flow and to perform the task in a bulk mode? I wonder as well.
@VinceFINET With regards to your 1st and 2nd point, this is exactly what I have been working on and testing as well. I need to make some small modifications to the Typescript module of the flow scanner to be fully supported as static resource in SF, but I do think it is the right way to do it.
There are still a lot of optimization we can do to improve performance, like processing flows asynchronously in bulk which is not hard to do. Maybe in the first version we can have a separate button/page to run these additional rules, so it does not directly affect the performance of OrgCheck?
Ill be working on the first point this week and also supporting the Tooling API format as a sort of Proof of Concept. If it suits you, maybe we can then connect again and work out the details!
@VinceFINET Its been a long while since we spoke, for which my apologies. When playing around with this, I realized there are a lot potential performance challenges to implement this in the front end.
It seems to make the most sense that this remains an sfdx operation, and the results can then be uploaded asynchronously(using Tableau i.e.). If you are still interested, I do have a POC around that.
ok si i will close this ticket as you will focus on the sfdx part, which is not at this time yet a thing for Org Check.