Terraform does not currently have first-class support for this sort of arbitrary action, since its workflow is designed around the common verbs Create, Read, Update, Delete.
However, similar to how we can model arbitrary actions in a REST API using
POST, we can potentially model arbitrary actions in Terraform using
Create as long as there’s a means within the resource configuration to allow the user to indicate when the action might need to be taken again in future, after the object is already created.
null_resource resource type is a simple example of this technique: it doesn’t actually do anything by default, but it can be used to house provisioners whose execution is not tied to the creation of any specific object. It has a
triggers map which is implemented such that any change to its value (compared to what is saved in the Terraform state) will cause the object to be recreated.
Your “workflow execution” resource type could follow a similar model: call the remote API to trigger the workflow in the resource type’s
Create function, and then have an arbitrary map attribute that is marked in the schema as
ForceNew: true so users of that resource type can indicate which changes should prompt a re-execution of the workflow.
For a resource type like this, usually all of the arguments in the schema will be marked as
ForceNew: true and the resource type won’t have an
Update implementation at all: any change to the settings would then prompt re-running the workflow.
That’s not mandatory, though… if in your case it would be useful to be able to change the workflow execution settings for a future execution without actually executing the workflow then you could choose instead to have a completely empty
Update implementation and thus effectively ignore any changes except on the arguments specifically configured as