One shouldnt have to go into a development interface to create a virtual switch to trigger an automation, Jody.
The way the UI choice has been described to end users is:
Scenes are collections of settings
Automations are calculations and decisions based on reactions to triggers.
It just makes sense that an external factor such as Alexa or GH with an official integration should be able to trigger the automations as well.
Scenes are fine for some things, but are limited in scope. Yes, I use virtual switches when necessary, but this is a kludge and an extra step that should not be necessary. Much cleaner to invoke an Automation directly, just like you can with a Routine today.
Can you explain your use case? I have some ideas, but it would help the developers what you really want to achieve.
That to me is the real problem.
I see sense in splitting up the actions of a Routine, which can be directly activated, from the optional automatic triggering component, which could then be reusable for other purposes.
If all the actions available to an Automation were available in a Scene then it would be job done, and indeed game changing.
Instead the ability to directly activate the payload has been lost.
Routines have not been replaced by Automations and Scenes, which it is how it is presented. That would have been fine. Instead theyâve been replaced by Automations and lost functionality. Scenes remain as marginal as ever.
One of the decisions every framework developer has to make is what to do with filtered actions. 
For example, if someone has a routine/automation to unlock the garage cabinet which is set to run only when Michael comes home, itâs Friday, the time is between 7 am and 9 pm, and the garage light is on, which weâll call Automation One, what should happen if that is automatically exposed to Alexa? That is, when someone says, âAlexa, turn on Automation One,â should the cabinet immediately unlock?
Should it unlock only if all the other conditions are met?
Will Alexa check the conditions or will the automation hub do so?
This is the standard home automation industry distinction between a âsceneâ and a âroutine.â A scene is unfiltered, and therefore available to be actuated by routines or buttons or voice assistants.
A routine has filter options, and therefore typically is not exposed to voice assistants.
SmartThings history
SmartThings was unusual in that it developed routines before it developed scenes. So back in 2016, it exposed its routines to Alexa by identifying them as scenes. Which they werenât, because they had filters, but they didnât have many filters and it worked OK.
Then over the years SmartThings added true scenes and in 2018 introduced the new V3 app with much more complex automations (no longer called âroutines,â although I donât know why.)
So now SmartThings matches the industry in having actionable âscenesâ and filtered âroutinesâ (which SmartThings calls âautomationsâ) and, as is typical, exposes ALL scenes to voice assistants, but not its automations. So far, so good. 
Not exposing automations avoids the question of what to do with the filters.
Going forward
If SmartThings changes it up and exposes automations to the voice assistants, that introduces two major safety issues,
How will filters be handled?
At the present time, ALL ST devices and scenes are exposed to both Alexa and Google Home. As of early 2020 you can no longer selectively enable voice authorization. So what happens when someone in the home misspeaks and unintentionally triggers an ST automation normally used only in emergencies? Itâs going to get messy. 
The workaround for 1. Is typically similar to what SmartThings has done with the Logitech Harmony integration: have ST create virtual buttons to represent each automation and expose those to the voice assistants as devices, leaving all the filter processing on the ST side. This is the same as creating your own virtual switch, it just does it for you.
But right now thereâs no workaround for 2 and, as I mentioned, it introduces a huge number of potential safety and parental control issues. 
I donât have a good design strategy to suggest. But I did just want to mention that there is a real reason why the industry generally distinguishes between IOT âscenesâ and âroutines.â And this distinction has become even more important with the introduction of voice assistants.
FWIW
@Gwalker88 @orangebucket @jody.albritton @nathancu @GSzabados
I disagree. I have many automations and I donât want all of them exposed to Alexa for the reasons JD outlined. Scenes makes it easy to differentiate the groups of actions i want available to both automations and voice control.
Understandable, and I totally get the fact itâs a design decision. Although, I would submit that the exact reason you point out (filterable) is the reason WHY Automations should be exposed⊠I also want the ability to filter what the Voice Assistants âseeâ back, but thatâs a completely different rant and feature request. In my case Iâd almost always filter out all my scenes and only expose the automations if I were able.
If I say âAssistant, run Automation 1â It triggers- no questions asked. BUT the Automation Platform has the intelligence built in to determine if it SHOULD do the thing in Automation 1 or what conditions should be put on Automation 1 when it runs. âŠincluding safety concerns. (Which should always be applied closest to the common point of activation anyway.)
Nor do I. I donât want any of them exposed.
My point is that the only reason you might want Alexa to run an Automation is to ignore the conditions and just execute the actions, as you could do with Routines. The only reason you might need to do that is because you canât currently put all the actions an Automation can execute into a Scene.
Yes, I agree. My point is that, if you can only use Scenes to control devices and set the location mode, you can only do that with a subset of actions.
So, Iâm still missing it . How can I migrate?
Ugh⊠apparently this is not ready for prime time. Needs pushed back⊠a lot. If this is pushed out too soon, your support team is going to crashâŠlike the new app.
Think Iâve found a bug⊠Trying to create an automation in the New App to turn a switch off after 10 minutes following the trigger. So I set it up, switch the Delay This Action to 10 minutes, the delay is set and when you go back to the edit screen the delay is shown as 10 minutes. However, if you then go to change the delay, the delay is no longer set. If you set to come on after 10 minutes it all works fine. BTW, this is iOS only. Seems to work fine on AndroidâŠ
This means that youâre using features that were still being worked on/tested. You should see the banner soon, but I canât give exact timing. Just know that itâs hard to miss once itâs showing. 
What is really needed is a way to choose what ST notifications are ment to who. As You suddenly took SMS capability away from us there is no other way than send all push notifications to all users. Now my kids are getting notifications that are ment to parents. Now my wife is getting multiple notifications per day which for her⊠are useless.
Also Iâm loving the idea that if somebody brakes to my house we are all getting information about it. Iâm not loving the idea where Iâm alone in home and my wife and kids are other side on planet. They are getting infomation about that door has been open more than 15minutes.
Is there any chance to add possibility to choose which push notifications are sent and who they are sent?
Like other useful features this used to be a capability of smart things but they removed the âmy contactsâ feature some time agoâŠ
I would like to see a popup saying what it holding me up from migrating. Maybe I have old stuff I can get rid of that is marking me as not ready yet. Or I could find a new way with the new app that accomplishes what the hold up is. If I saw the list in the popup shrink, it would give me give me insight as things are fixed and could provide feedback into how those things operate. Unfortunately, it is a combination of backend changes and app updates, which either are never announced, or summed up in an announcement as âbugfixes and whatnotâ.
I understand where youâre coming from and this is a great idea, but in full transparency, building something like this would distract from the development efforts to get everything working properly and migration completed.
As I mentioned WAY back in this thread, the main things that the migration tool will help with are converting routines to scenes and automations, and porting over your lock code management and SHM settings. Youâre welcome to make those changes yourself and start using the new app. Either way, the team here appreciates your enthusiasm 
I figured. I use the new app for most things now, but would rather wait for the migration to change my routines over. Thatâs a fair amount of work I donât want to replicate
Iâm at a loss when trying to make my custom (Window Shade) DTH work in the new app. All of the functions are triggering actions (eg. shade moves and displays battery status etc) but every button press in the new SmartThings app results in a âA network or server error occurred. Try again laterâ error message after a timeout (despite it actually working just fine!)
As a test I have simplified my on() and off() functions to the following (so that they donât make HubAction calls etc) and I still get the error message in the new SmartThings app. This error does not occur in the classic SmartThings app!
Here is the simplified on() and off() methods Iâm testing with:
def on() {
log.debug "Device ID: $device.deviceNetworkId on() was triggered"
sendEvent(name: "switch", value: "on", isStateChange: true)
}
def off() {
log.debug "Device ID: $device.deviceNetworkId off() was triggered"
sendEvent(name: "switch", value: "off", isStateChange: true)
}
Does anyone know what could be causing this as Iâm at wits end!
probably that weird glitch in the app/appserver thatâs come up in the last several days. I am still hoping an official smartthings rep will notice the posts about it. Mine all work fine, in spite of showing as offline lol
I have noticed that the error appears when, for example, the âon()â command doesnât result in the attribute eventually changing to âonâ within a timeout period. Where the Classic app would get stuck in âturning onâ (if used), the new app gives the error.
However your test would seem to destroy that line of thinking, unless the âon()â and âoff()â commands are being used for other attributes.