​Create the event.

​Use Test Get Calendar Events to find the newly created Event ID.

​Use Calendar Update to apply the color.

​The Solution: Add a Color input field directly within the Calendar Insert action. This field should ideally support:

​Alternatively, you can slightly optimize the process by outputting the event id as local variable from the Calendar Insert action.

​If

​Create the event.

​Use Test Get Calendar Events to find the newly created Event ID.

​Use Calendar Update to apply the color.

​The Solution: Add a Color input field directly within the Calendar Insert action. This field should ideally support:

​Alternatively, you can slightly optimize the process by outputting the event id as local variable from the Calendar Insert action.

​If

Currently, navigating two or three levels deep into a submenu, only to realize you are in the wrong place, requires returning all the way to the three dots menu to start over. A small back button at each menu level would resolve this and meaningfully reduce friction for frequent users.

Given that the component already exists in Scenes v2, this feels like a natural carry-over rather than a net-new build. Small quality-of-life improvements like this compound over time and go a long way toward keeping the experience polished.

Thank you for considering it, and for everything you continue to put into Tasker.

​Create the event.

​Use Test Get Calendar Events to find the newly created Event ID.

​Use Calendar Update to apply the color.

​The Solution: Add a Color input field directly within the Calendar Insert action. This field should ideally support:

​Alternatively, you can slightly optimize the process by outputting the event id as local variable from the Calendar Insert action.

​If

However, when Tasker needs the user to select an image, the resulting file picker does not contain image sources in the Open from view. It's just a plain file picker.

As it is now, user must extract icons from packs and place the images in a folder so that the file picker can find them. It would save the user a lot of time if Tasker used the Open from menu variant that presents image sources. This would be particularly useful when using Tasker to create scenes and widgets.

Screenshots showing difference between the file pickers:

"normal" file picker

"image sources" file picker

Additionally, i suggest to put the values of variables under its names instead of right from it (on the "Vars" tab), because these can be long as well and it would be more easy to read if they take whole width of the screen.

I hope this can be implemented, i think, it will make the UI much more comfortable.

A Google searched yielded this: Google Copy/Paste Menu

I would suspect that there might be a way for Tasker to predeclare some Task Caller spots that the user could configure in preferences, much like many of the other areas the app has enabled enhancements for (Tiles, Share, etc.).

Screenshots:

- Dialog reference of the menu I'm referring to

- The extended portion of the menu where apps Google Translate and CoPilot have added their own options.

Additionally, i suggest to put the values of variables under its names instead of right from it (on the "Vars" tab), because these can be long as well and it would be more easy to read if they take whole width of the screen.

I hope this can be implemented, i think, it will make the UI much more comfortable.

A Google searched yielded this: Google Copy/Paste Menu

I would suspect that there might be a way for Tasker to predeclare some Task Caller spots that the user could configure in preferences, much like many of the other areas the app has enabled enhancements for (Tiles, Share, etc.).

Screenshots:

- Dialog reference of the menu I'm referring to

- The extended portion of the menu where apps Google Translate and CoPilot have added their own options.

Additionally, i suggest to put the values of variables under its names instead of right from it (on the "Vars" tab), because these can be long as well and it would be more easy to read if they take whole width of the screen.

I hope this can be implemented, i think, it will make the UI much more comfortable.

Additionally, i suggest to put the values of variables under its names instead of right from it (on the "Vars" tab), because these can be long as well and it would be more easy to read if they take whole width of the screen.

I hope this can be implemented, i think, it will make the UI much more comfortable.

In real-world usage, calendar events often don’t strictly follow their scheduled time. Meetings can start earlier or run longer than planned.

Example:
An event is scheduled from 10:00 to 10:30

• It may start at 09:45

• It may end at 11:00

To handle this, it would be very useful to add offset options directly to the State context:

• Start Early (minutes)

• End Later (minutes)

Example usage:

• Start Early = 20 → profile activates at 09:40

• End Later = 30 → profile remains active until 11:00

This would allow State-based profiles to better reflect real-life scenarios without requiring workarounds using Event contexts or polling logic.

This would be especially useful for things like:

• Automatically enabling silent/vibrate mode for meetings

• Smart home or notification automation

• Work schedules with flexible timing

Thanks for considering this improvement!

In real-world usage, calendar events often don’t strictly follow their scheduled time. Meetings can start earlier or run longer than planned.

Example:
An event is scheduled from 10:00 to 10:30

• It may start at 09:45

• It may end at 11:00

To handle this, it would be very useful to add offset options directly to the State context:

• Start Early (minutes)

• End Later (minutes)

Example usage:

• Start Early = 20 → profile activates at 09:40

• End Later = 30 → profile remains active until 11:00

This would allow State-based profiles to better reflect real-life scenarios without requiring workarounds using Event contexts or polling logic.

This would be especially useful for things like:

• Automatically enabling silent/vibrate mode for meetings

• Smart home or notification automation

• Work schedules with flexible timing

Thanks for considering this improvement!

In real-world usage, calendar events often don’t strictly follow their scheduled time. Meetings can start earlier or run longer than planned.

Example:
An event is scheduled from 10:00 to 10:30

• It may start at 09:45

• It may end at 11:00

To handle this, it would be very useful to add offset options directly to the State context:

• Start Early (minutes)

• End Later (minutes)

Example usage:

• Start Early = 20 → profile activates at 09:40

• End Later = 30 → profile remains active until 11:00

This would allow State-based profiles to better reflect real-life scenarios without requiring workarounds using Event contexts or polling logic.

This would be especially useful for things like:

• Automatically enabling silent/vibrate mode for meetings

• Smart home or notification automation

• Work schedules with flexible timing

Thanks for considering this improvement!

• content://com.samsung.android.app.routines.externalprovider/routine_list?routine_type=normal&condition_type=manual
  • condition_type can also be "auto," but this is not useful for Tasker because "auto" routines cannot be run manually
  • Also accepts query param "only enabled=0" which will return disabled routines as well
• content://com.samsung.android.app.routines.routineinfoprovider/manual_enabled_routines

• content://com.samsung.android.app.routines.domainmodel.routinetestprovider/routine_uuid_list
  • Also returns automatic routines

• content://com.samsung.android.app.routines.externalprovider
  • Flag should be one of {"start_manual_routine", "toggle_manual_routine", "end_manual_routine"}
  • Bundle should have one long of key "uuid" and value should be UUID of routine to be started/toggled/stopped
• content://com.samsung.android.app.routines.domainmodel.routinetestprovider
  • Flag should be one of {"run_routine", "stop_routine"}
  • Bundle should have one long of key "_uuid" and value should be UUID of routine to be started/toggled/stopped

1. adb shell pm path com.samsung.android.app.routines
2. adb pull <path from step 1>

Then I decompiled the APK with JADK. I looked in the manifest for services, receivers, and providers. Most of them require permissions that are locked to signature/system access only, the ones I found that are externally accessible were listed above.

• content://com.samsung.android.app.routines.externalprovider/routine_list?routine_type=normal&condition_type=manual
  • condition_type can also be "auto," but this is not useful for Tasker because "auto" routines cannot be run manually
  • Also accepts query param "only enabled=0" which will return disabled routines as well
• content://com.samsung.android.app.routines.routineinfoprovider/manual_enabled_routines

• content://com.samsung.android.app.routines.domainmodel.routinetestprovider/routine_uuid_list
  • Also returns automatic routines

• content://com.samsung.android.app.routines.externalprovider
  • Flag should be one of {"start_manual_routine", "toggle_manual_routine", "end_manual_routine"}
  • Bundle should have one long of key "uuid" and value should be UUID of routine to be started/toggled/stopped
• content://com.samsung.android.app.routines.domainmodel.routinetestprovider
  • Flag should be one of {"run_routine", "stop_routine"}
  • Bundle should have one long of key "_uuid" and value should be UUID of routine to be started/toggled/stopped

1. adb shell pm path com.samsung.android.app.routines
2. adb pull <path from step 1>

Then I decompiled the APK with JADK. I looked in the manifest for services, receivers, and providers. Most of them require permissions that are locked to signature/system access only, the ones I found that are externally accessible were listed above.

Also, it would be great if they were visually distinguished from local variables.

Having some kind of indication that there are variables Task/Profile/Project - Sometimes coming back to an old project you don't remember if you had your variables as a Task/Profile/Project.

The current Run Log is powerful but becomes hard to read with many automations running. Seeing only that specific task or profile's past runs would make debugging faster, clearer, and more approachable while keeping the global Run Log unchanged.