You won't get around needing to do individual calls as you'll need the details of metadata. When you make the PATCH
call to deactivate/activate them, you need to include more than just the active
property or you risk overwriting values with null (ex. description
field) or getting errors as certain fields are expected. In particular, workflow rules have a lot of sub items (WorkflowCritera
, WorkflowRuleActions
, WorkflowTimeTriggers
).
The other consideration to take is how you will know which rules were active after you've deactivated them - assuming the goal would be to later re-activate them when you want.
For this you can take different approaches depending on the goal
- No inactive rules should exist in an org. They should be deleted. Leverage source control if you ever need to refer to them again
- Leverage a custom object or platform cache to store which rules were active.
Otherwise, your approach is the general way to go about it.
- Query all validation rules and workflow rules in the way you outlined for Validation Rule (per object). For Workflow Rules, you can leverage
WHERE TableEnumOrId = 'Case' OR...
to get them per object.
- Make calls for each individual one to get their metadata as you need it regardless to pass the complete metadata information (with
active
changed only in your logic afterwards). You can utilize the URL returned in the first query above to know what endpoint to use for getting the metadata and updating it. url
under attributes
will contain that endpoint as shown below
{
"size" : 2,
"totalSize" : 2,
"done" : true,
"queryLocator" : null,
"entityTypeName" : "WorkflowRule",
"records" : [ {
"attributes" : {
"type" : "WorkflowRule",
"url" : "/services/data/v52.0/tooling/sobjects/WorkflowRule/01Q4P000000pB6fUAE"
},
"Id" : "01Q4P000000pB6fUAE",
"Name" : "test"
}, {
"attributes" : {
"type" : "WorkflowRule",
"url" : "/services/data/v52.0/tooling/sobjects/WorkflowRule/01Q4P000000UxejUAC"
},
"Id" : "01Q4P000000UxejUAC",
"Name" : "test2"
} ]
}
- Heavily leverage composite requests to bundle the above calls (25 requests in one) into less calls (including the updates). This should make this more doable.
/services/data/v53.0/tooling/composite
{
"compositeRequest" : [
{
"method" : "PATCH",
"url" : "/services/data/v53.0/tooling/sobjects/WorkflowRule/RuleId",
"referenceId" : "workflow1",
"body" : { "Metadata" : "pass your metadata queried before here with active changed" }
},
{
"method" : "PATCH",
"url" : "/services/data/v53.0/tooling/sobjects/WorkflowRule/Rule2Id",
"referenceId" : "workflow2",
"body" : { "Metadata" : "pass your metadata queried before here with active changed" }
}
...up to 25
]
}
As an aside, if you already leverage apex-mdapi - you could look to accomplish what you want through there.