Suggestion to handle 'required' resources or default resources created in new Twilio accounts with less friction

[stephenhand]

Issue Summary

Twilio accounts have some resources that are required, and are created as part of a new account, but are not recognised automatically as part of terraform. Some of these appear to be just defaults to get you started, but others appear to be required and have a special status.

For example, one of the serverless services is required and should not be removed, and Flex only uses the 'default' versions of some components, like Chat or Conversations services

In order to handle this, we have had to employ workarounds to import these resources when we create new accounts:

https://github.com/techmatters/flex-plugins/blob/master/scripts/src/terraformSupplemental/importDefaultTwilioResourcesToTerraform.ts

However this isn't a foolproof solution, and it has been a source of significant headaches when the default resources created by new accounts change.

Ideally we should be able to work with newly created Twilio accounts via the terraform provider without having to import resources first, and should thereafter know which versions of resources are required or special versions from their Terraform configuration, rather than it having to be tracked separately

Suggested Change

• Have the option to create 'bare bones' Twilio accounts, where nothing is added but the absolute minimum required, with the assumption that terraform will take care of the rest, so importing resources isn't required
• Call out the 'special' versions of resources in the terraform provider resources. This could be done either:
  • By being able to designate which resource has the special status via a property flag i.e. default = true for a default conversations service.
  • Having a separate type of resource for configuring the required default resource, e.g. twilio_default_serverless_service_config_v1, and only have the twilio_serverless_services_v1 used for creating additional serverless services

[childish-sambino]

Agreed. We've had the second option in our backlog for a while (reference DI-1050), but it's not been prioritized.

Pull requests and +1s on the issue summary will help it move up the backlog.

[twilio-jyoung]

agreed that this is difficult to work with in flex environments which spin up lots of default resources.

a phone number, taskrouter config, studio flows, conversations services, chat services, proxy services, flex conversation addresses (undocumented as far as i can tell), etc...