I’m developing a provider plugin and I have a little unusual scenario where I need a way to trigger a function that applies a change to the resource without any change in the TF config file. The function requires no parameters (it’s a sort of “self rotate”). I could add a dummy attribute to the resource schema and have a change in the value of the field trigger the update function, but that’s not the user experience I want to have. One option I considered is to have my provider read function check the value of some custom TF variable that will act as a flag that would tell the read function to apply the change to the resource (call our backend API) and then continue with the normal read. I could then call “Terraform refresh -var=<var_with_flag_value>”, and that would trigger the change function and refresh the state. Is there a more standard way to trigger a custom function which is not one of the CRUD functions?
Without any more information, I’d have to say that this sounds like something you should do entirely outside of Terraform.
Hi @haims 
Welcome to the HashiCorp Discuss forums and thank you for raising an interesting question.
In general, Terraform managed resources are expected to be a component with Create, Read, Update, and Delete functionality. The full details of this lifecycle are described in the Resource Instance Change Lifecycle documentation in the core repository. The Terraform website also has been recently updated with additional information in this regard on the Terraform Plugin Protocol page. These resources may be quite advanced, if you are unfamiliar with some of the internals of how Terraform works though.
While its sometimes possible to shim various “not managing a particular component” operations into the typical resource lifecycle, such as creating a resource that “runs” once by nature of only including logic in the Create method, it can quickly become problematic without careful consideration. Practitioners typically expect certain behaviors to occur with Terraform, such as resource or data source refresh/Read not having side-effects. One fun tidbit when you get deep enough into Terraform’s internally is that technically the PlanResourceChange RPC is called regardless of configuration changes. This would allow the provider, for example, to signal a plan difference for apply regardless of a configuration update. The same note about careful consideration applies here though, as practitioners could be annoyed if Terraform constantly showed changes for a theoretical resource implementing this behavior without a way to opt-out.
As @maxb mentions, I think it would be generally good if we had a little more description of the end goal of what you are trying to accomplish so we can determine if its something “valid” for a typical Terraform resource or workflow.