deanishe

You don't need Alfred for this. It's built in to OS X.

There may be a better way to do this, but this is what I did, and now the Caffeinate Control workflow works for me.
I tried to make a step-by-step guide for you. Hope it helps!
 
Step 1
Open up Alfred Preferences and go to the Workflows tab
In your list of workflows, right click "Caffeinate Control" and do Open in Finder, like this:
 

 
Step 2
Now you should have a Finder window open to the Caffeinate Control workflow directory, like this:
 

 
I have highlighted the 2 files you will be editing: conf-and-help.scpt and library.sh
 
Step 3
Open conf-and-help.scpt, which will launch the Script Editor
Search for "Alfred", and you will find this line:
 

 
Yours will say Alfred 2, so change it to Alfred 3 like in mine
Save the script and quit the Script Editor
 
Step 4
Open library.sh in a text editor (I used Sublime Text, but TextEdit or any other text editor is fine)
Search for "Alfred", and you will find these 2 lines:
 

 
Yours will say Alfred-2 and Alfred 2, so change them to Alfred-3 and Alfred 3 like in mine
Save the file and quit your text editor
 
That's it! Now the Caffeinate Control workflow should be working again 
 
(Note: after completing these steps, you might have to quit Alfred and then restart Alfred, but I'm not sure if that's necessary - I can't remember if I had to do that or not, but if it's still not working for you, then try that.)

The AS just runs a quick pop-up for the configuration, so that problem does not apply. There is no tell Alfred 2 or Alfred 3 in there (unless I'm totally forgetting something from code that I wrote three years ago -- total possibility).
 
(Although you could get around that problem by checking to see if they are installed, and wrapping the tell statements in an if, etc...)

You don't need Alfred for this. It's built in to OS X.

It would be great to be able to hold a modifier key when opening an app from Alfred, and have it open in the background without stealing focus.
 
This can be done from the command line with 
 
open -g path/to/app
 
and I could create workflows for each of my commonly used apps to allow this....but it would be great as a built-in feature.

Note: This post is out of date as of Alfred 3.6 (which introduced AppleScript functions to set and remove variables).

There is an updated version on my own site: Workflow/environment variables in Alfred.

This post will not be updated due to the difficulty of editing complex posts using the forum software. Sorry.
 
 
This is a brief look at how to get, set and save variables in code (i.e. in Script Filters, Run Script Actions, etc.).

In Alfred 2, you had one single variable to work with: the {query} macro. Alfred 3 adds the ability to specify as many variables as you want. Alfred's own help provides a great description of working with variables in Alfred's own UI. I'm going to look more closely about getting and setting workflow/environment variables in your own code within a workflow.

First of all, it bears mentioning that all variables are strings. Sure, you can set a variable to a number in JSON, but when it reaches your next script or one of Alfred's Filter Utilities, it will be a string. If you set a variable to an array (e.g. [1, 2, 3, "mach dat Mäh mal ei"]), Alfred will turn it into a single, tab-delimited string ("1\t2\t3\tmach dat Mäh mal ei").

Setting variables

There are several ways to set variables. The most obvious ones are in the Workflow Environment Variables table in the workflow configuration sheet and using the Arg and Vars Utility. The configuration sheet is largely without magic, but in an Args and Vars Utility, you can use variable expansion macros: {query} expands (as always) to the input (which may be a user-entered query or the output from a previous Action), and you can use {var:VARIABLE_NAME} macros for your own custom variables.  This is described in detail in the above-mentioned help pages.

More interestingly, you can also set variables via the output of your scripts (i.e. dynamically) by emitting appropriate JSON. How you set variables depends on whether you are using a Script Filter or a Run Script action.

You must use the appropriate mechanism, or it won't work.

From Run Script actions

Let's say your script outputs a URL, e.g. https://www.google.com. Normally you just do print('https://www.google.com') (or echo or puts) and that gets passed as the input to the next action. To also pass variables, you instead emit JSON in a very specific format:
{"alfredworkflow": {     "arg": "https://www.google.com",     "variables": {"browser": "Google Chrome"}}} The root alfredworkflow object is required. If it's missing, Alfred won't parse the JSON, but will pass it as-is as input to the next action (which can also be very useful). Your output (i.e. the next Action's input/{query}) goes in arg, and any variables you wish to set go in the variables object.

From Script Filters

You can also set workflow variables via Script Filter feedback at three different levels: the root level, the item level and the modifier level. (Note: This only applies to JSON feedback; XML feedback is now deprecated and does not support the features described here.)

In each case, variables are set via a variables object at the appropriate level (feedback root, item or mod).

Root-level variables

Root-level variables are always passed to downstream elements regardless of which item is actioned. They are also passed back to the same Script Filter if you've set rerun, so you can use root-level variables to implement a progress bar.

browser is set to Safari for all items:
{"variables": {"browser": "Safari"},  "items": [{"title": "Google",    "arg": "https://www.google.com"}]}
Item-level variables

Item-level variables are only passed downstream when the item they're set on is actioned, and they override root-level variables. Root-level variables are also passed downstream when you action an item.

browser is set to Safari by default, but Google Chrome for Reddit:
{"variables": {"browser": "Safari"},  "items": [    {"title": "Google",      "arg": "https://www.google.com"},    {"title": "Reddit",      "arg": "https://reddit.com",      "variables": {"browser": "Google Chrome"}}]}
Modifier-level variables

Modifier-level variables are only passed downstream when the corresponding item is actioned with the appropriate modifier key pressed. They replace item- and root-level variables (i.e. if a modifier sets any variables, Alfred ignores any root- and item-level variables).

As above, browser is set to Safari by default and Google Chrome for Reddit. But you can also pass browser=Google Chrome for Google by holding ⌘ when actioning it:
{"variables": {"browser": "Safari"},  "items": [    {"title": "Google",      "arg": "https://www.google.com",      "mods" {"cmd": {"variables": {"browser": "Google Chrome"}}}},    {"title": "Reddit",      "arg": "https://reddit.com",      "variables": {"browser": "Google Chrome"}}]}
Using variables

So you've set a few variables, and now you want to use them. Within Alfred elements like Arg and Vars or Filter Utilities, you use the above-mentioned {var:VARIABLE_NAME} macros. Very simple.

Where it gets a little more complicated is in your own code. First and foremost, {var:VARIABLE_NAME} macro expansion does not work in Run Script Actions (or Run NSAppleScript).

When Alfred runs your code, it does not use {var:...} macros, but rather takes any workflow variables and sets them as environment variables for your script. Using the above example again, Alfred would pass "https://www.google.com" to my script as input (either via ARGV or {query} depending on the settings) and it would set the environment variable browser to Safari or Google Chrome. How you retrieve environment variables depends on the language you're using.

Accessing environment variables in different languages

In bash/zsh, the variables are already in the global namespace. Just use $browser

In Python, use the os.environ dictionary or os.getenv('VARIABLE_NAME'):
import os browser = os.environ['browser'] # Or browser = os.getenv('browser')
In AppleScript, use system attribute:
set theBrowser to (system attribute "browser")
In JavaScript (JXA), use $.getenv():
ObjC.import('stdlib') var browser = $.getenv('browser')
In PHP, use getenv():

(Please see this comment by juliosecco on why you should use getenv() over $_ENV.)
$browser = getenv('browser'); // Or $browser = $_ENV['browser'];
In Ruby, use ENV:
browser = ENV["browser"]
Saving variables
 
NOTE: This section is out of date as of Alfred 3.6. Please see the updated version linked at the top of the post.
 
As amoose136 points out, any variables you set in a running workflow are not saved. They exist as long as the workflow is running and then disappear. Any Workflow Environment Variables will "reset" to their values in the workflow configuration sheet on the next run.

Generally, this is what you want, but sometimes you want to save a variable's value. For example, you might have an API_KEY Workflow Environment Variable in the configuration sheet. The user can enter their API key for the service in the configuration sheet, but you'd also like to add the ability to set it from within your workflow, e.g. with a setapikey Keyword and corresponding Run Script action.

WARNING: As of Alfred 3.4.1, Alfred takes several seconds to notice when info.plist has been updated by something other than itself. As a result, relying on altering info.plist programatically can be problematic, as Alfred won't notice the changes for several seconds (5–10 seconds is typical on my machine). If you update a workflow variable in info.plist and run your workflow again immediately, it is unlikely that Alfred will have picked up the change.

The Workflow Environment Variables are contained in the variables section of info.plist. Consequently, to update them, you need to update info.plist.

Regardless of which language you're using, you can call the PlistBuddy program to alter Workflow Environment Variables:
# Set a variable /usr/libexec/PlistBuddy -c "Set :variables:API_KEY \"ABC-XYZ\"" info.plist # Delete a variable (i.e. remove it entirely from Workflow Environment Variables) /usr/libexec/PlistBuddy -c "Delete :variables:API_KEY" info.plist
In Python, there's no need to use an external program, as it has the built-in plistlib library:
from plistlib import readPlist, writePlist # Read info.plist into a standard Python dictionary info = readPlist('info.plist') # Set a variable info['variables']['API_KEY'] = 'ABC-XYZ' # Delete a variable del info['variables']['API_KEY'] # Save changes writePlist(info, 'info.plist')
(Note: plistlib only works with XML property lists, which is fine for info.plist, but using PlistBuddy is generally more robust.)

Don't forget: any changes you make to info.plist only take effect the next time the workflow is run. This likely doesn't matter in most cases, but if you need a variable to be updated immediately (i.e. also for the current workflow run), you must also set it "live" using one of the methods described in the Setting variables section above.

 

I just posted a thread describing how to get and set variables in code.
 
I've stickied it for the time being. I guess Vero or Andrew will unsticky it if that's not okay.

This is something I'm considering adding to Alfred-Workflow, kinda like an HTTP session. Version 2 is going to be a straight port of the v1 API to Alfred 3 (although it's very different internally), but I hope to add something more useful to v3 once we've all figured out the best way to work with Alfred 3.
When Andrew adds internal triggers, it might be possible to build quite a powerful API on top of them.

Note: This post is out of date as of Alfred 3.6 (which introduced AppleScript functions to set and remove variables).

There is an updated version on my own site: Workflow/environment variables in Alfred.

This post will not be updated due to the difficulty of editing complex posts using the forum software. Sorry.
 
 
This is a brief look at how to get, set and save variables in code (i.e. in Script Filters, Run Script Actions, etc.).

In Alfred 2, you had one single variable to work with: the {query} macro. Alfred 3 adds the ability to specify as many variables as you want. Alfred's own help provides a great description of working with variables in Alfred's own UI. I'm going to look more closely about getting and setting workflow/environment variables in your own code within a workflow.

First of all, it bears mentioning that all variables are strings. Sure, you can set a variable to a number in JSON, but when it reaches your next script or one of Alfred's Filter Utilities, it will be a string. If you set a variable to an array (e.g. [1, 2, 3, "mach dat Mäh mal ei"]), Alfred will turn it into a single, tab-delimited string ("1\t2\t3\tmach dat Mäh mal ei").

Setting variables

There are several ways to set variables. The most obvious ones are in the Workflow Environment Variables table in the workflow configuration sheet and using the Arg and Vars Utility. The configuration sheet is largely without magic, but in an Args and Vars Utility, you can use variable expansion macros: {query} expands (as always) to the input (which may be a user-entered query or the output from a previous Action), and you can use {var:VARIABLE_NAME} macros for your own custom variables.  This is described in detail in the above-mentioned help pages.

More interestingly, you can also set variables via the output of your scripts (i.e. dynamically) by emitting appropriate JSON. How you set variables depends on whether you are using a Script Filter or a Run Script action.

You must use the appropriate mechanism, or it won't work.

From Run Script actions

Let's say your script outputs a URL, e.g. https://www.google.com. Normally you just do print('https://www.google.com') (or echo or puts) and that gets passed as the input to the next action. To also pass variables, you instead emit JSON in a very specific format:
{"alfredworkflow": {     "arg": "https://www.google.com",     "variables": {"browser": "Google Chrome"}}} The root alfredworkflow object is required. If it's missing, Alfred won't parse the JSON, but will pass it as-is as input to the next action (which can also be very useful). Your output (i.e. the next Action's input/{query}) goes in arg, and any variables you wish to set go in the variables object.

From Script Filters

You can also set workflow variables via Script Filter feedback at three different levels: the root level, the item level and the modifier level. (Note: This only applies to JSON feedback; XML feedback is now deprecated and does not support the features described here.)

In each case, variables are set via a variables object at the appropriate level (feedback root, item or mod).

Root-level variables

Root-level variables are always passed to downstream elements regardless of which item is actioned. They are also passed back to the same Script Filter if you've set rerun, so you can use root-level variables to implement a progress bar.

browser is set to Safari for all items:
{"variables": {"browser": "Safari"},  "items": [{"title": "Google",    "arg": "https://www.google.com"}]}
Item-level variables

Item-level variables are only passed downstream when the item they're set on is actioned, and they override root-level variables. Root-level variables are also passed downstream when you action an item.

browser is set to Safari by default, but Google Chrome for Reddit:
{"variables": {"browser": "Safari"},  "items": [    {"title": "Google",      "arg": "https://www.google.com"},    {"title": "Reddit",      "arg": "https://reddit.com",      "variables": {"browser": "Google Chrome"}}]}
Modifier-level variables

Modifier-level variables are only passed downstream when the corresponding item is actioned with the appropriate modifier key pressed. They replace item- and root-level variables (i.e. if a modifier sets any variables, Alfred ignores any root- and item-level variables).

As above, browser is set to Safari by default and Google Chrome for Reddit. But you can also pass browser=Google Chrome for Google by holding ⌘ when actioning it:
{"variables": {"browser": "Safari"},  "items": [    {"title": "Google",      "arg": "https://www.google.com",      "mods" {"cmd": {"variables": {"browser": "Google Chrome"}}}},    {"title": "Reddit",      "arg": "https://reddit.com",      "variables": {"browser": "Google Chrome"}}]}
Using variables

So you've set a few variables, and now you want to use them. Within Alfred elements like Arg and Vars or Filter Utilities, you use the above-mentioned {var:VARIABLE_NAME} macros. Very simple.

Where it gets a little more complicated is in your own code. First and foremost, {var:VARIABLE_NAME} macro expansion does not work in Run Script Actions (or Run NSAppleScript).

When Alfred runs your code, it does not use {var:...} macros, but rather takes any workflow variables and sets them as environment variables for your script. Using the above example again, Alfred would pass "https://www.google.com" to my script as input (either via ARGV or {query} depending on the settings) and it would set the environment variable browser to Safari or Google Chrome. How you retrieve environment variables depends on the language you're using.

Accessing environment variables in different languages

In bash/zsh, the variables are already in the global namespace. Just use $browser

In Python, use the os.environ dictionary or os.getenv('VARIABLE_NAME'):
import os browser = os.environ['browser'] # Or browser = os.getenv('browser')
In AppleScript, use system attribute:
set theBrowser to (system attribute "browser")
In JavaScript (JXA), use $.getenv():
ObjC.import('stdlib') var browser = $.getenv('browser')
In PHP, use getenv():

(Please see this comment by juliosecco on why you should use getenv() over $_ENV.)
$browser = getenv('browser'); // Or $browser = $_ENV['browser'];
In Ruby, use ENV:
browser = ENV["browser"]
Saving variables
 
NOTE: This section is out of date as of Alfred 3.6. Please see the updated version linked at the top of the post.
 
As amoose136 points out, any variables you set in a running workflow are not saved. They exist as long as the workflow is running and then disappear. Any Workflow Environment Variables will "reset" to their values in the workflow configuration sheet on the next run.

Generally, this is what you want, but sometimes you want to save a variable's value. For example, you might have an API_KEY Workflow Environment Variable in the configuration sheet. The user can enter their API key for the service in the configuration sheet, but you'd also like to add the ability to set it from within your workflow, e.g. with a setapikey Keyword and corresponding Run Script action.

WARNING: As of Alfred 3.4.1, Alfred takes several seconds to notice when info.plist has been updated by something other than itself. As a result, relying on altering info.plist programatically can be problematic, as Alfred won't notice the changes for several seconds (5–10 seconds is typical on my machine). If you update a workflow variable in info.plist and run your workflow again immediately, it is unlikely that Alfred will have picked up the change.

The Workflow Environment Variables are contained in the variables section of info.plist. Consequently, to update them, you need to update info.plist.

Regardless of which language you're using, you can call the PlistBuddy program to alter Workflow Environment Variables:
# Set a variable /usr/libexec/PlistBuddy -c "Set :variables:API_KEY \"ABC-XYZ\"" info.plist # Delete a variable (i.e. remove it entirely from Workflow Environment Variables) /usr/libexec/PlistBuddy -c "Delete :variables:API_KEY" info.plist
In Python, there's no need to use an external program, as it has the built-in plistlib library:
from plistlib import readPlist, writePlist # Read info.plist into a standard Python dictionary info = readPlist('info.plist') # Set a variable info['variables']['API_KEY'] = 'ABC-XYZ' # Delete a variable del info['variables']['API_KEY'] # Save changes writePlist(info, 'info.plist')
(Note: plistlib only works with XML property lists, which is fine for info.plist, but using PlistBuddy is generally more robust.)

Don't forget: any changes you make to info.plist only take effect the next time the workflow is run. This likely doesn't matter in most cases, but if you need a variable to be updated immediately (i.e. also for the current workflow run), you must also set it "live" using one of the methods described in the Setting variables section above.

 

Note: This post is out of date as of Alfred 3.6 (which introduced AppleScript functions to set and remove variables).

There is an updated version on my own site: Workflow/environment variables in Alfred.

This post will not be updated due to the difficulty of editing complex posts using the forum software. Sorry.
 
 
This is a brief look at how to get, set and save variables in code (i.e. in Script Filters, Run Script Actions, etc.).

In Alfred 2, you had one single variable to work with: the {query} macro. Alfred 3 adds the ability to specify as many variables as you want. Alfred's own help provides a great description of working with variables in Alfred's own UI. I'm going to look more closely about getting and setting workflow/environment variables in your own code within a workflow.

First of all, it bears mentioning that all variables are strings. Sure, you can set a variable to a number in JSON, but when it reaches your next script or one of Alfred's Filter Utilities, it will be a string. If you set a variable to an array (e.g. [1, 2, 3, "mach dat Mäh mal ei"]), Alfred will turn it into a single, tab-delimited string ("1\t2\t3\tmach dat Mäh mal ei").

Setting variables

There are several ways to set variables. The most obvious ones are in the Workflow Environment Variables table in the workflow configuration sheet and using the Arg and Vars Utility. The configuration sheet is largely without magic, but in an Args and Vars Utility, you can use variable expansion macros: {query} expands (as always) to the input (which may be a user-entered query or the output from a previous Action), and you can use {var:VARIABLE_NAME} macros for your own custom variables.  This is described in detail in the above-mentioned help pages.

More interestingly, you can also set variables via the output of your scripts (i.e. dynamically) by emitting appropriate JSON. How you set variables depends on whether you are using a Script Filter or a Run Script action.

You must use the appropriate mechanism, or it won't work.

From Run Script actions

Let's say your script outputs a URL, e.g. https://www.google.com. Normally you just do print('https://www.google.com') (or echo or puts) and that gets passed as the input to the next action. To also pass variables, you instead emit JSON in a very specific format:
{"alfredworkflow": {     "arg": "https://www.google.com",     "variables": {"browser": "Google Chrome"}}} The root alfredworkflow object is required. If it's missing, Alfred won't parse the JSON, but will pass it as-is as input to the next action (which can also be very useful). Your output (i.e. the next Action's input/{query}) goes in arg, and any variables you wish to set go in the variables object.

From Script Filters

You can also set workflow variables via Script Filter feedback at three different levels: the root level, the item level and the modifier level. (Note: This only applies to JSON feedback; XML feedback is now deprecated and does not support the features described here.)

In each case, variables are set via a variables object at the appropriate level (feedback root, item or mod).

Root-level variables

Root-level variables are always passed to downstream elements regardless of which item is actioned. They are also passed back to the same Script Filter if you've set rerun, so you can use root-level variables to implement a progress bar.

browser is set to Safari for all items:
{"variables": {"browser": "Safari"},  "items": [{"title": "Google",    "arg": "https://www.google.com"}]}
Item-level variables

Item-level variables are only passed downstream when the item they're set on is actioned, and they override root-level variables. Root-level variables are also passed downstream when you action an item.

browser is set to Safari by default, but Google Chrome for Reddit:
{"variables": {"browser": "Safari"},  "items": [    {"title": "Google",      "arg": "https://www.google.com"},    {"title": "Reddit",      "arg": "https://reddit.com",      "variables": {"browser": "Google Chrome"}}]}
Modifier-level variables

Modifier-level variables are only passed downstream when the corresponding item is actioned with the appropriate modifier key pressed. They replace item- and root-level variables (i.e. if a modifier sets any variables, Alfred ignores any root- and item-level variables).

As above, browser is set to Safari by default and Google Chrome for Reddit. But you can also pass browser=Google Chrome for Google by holding ⌘ when actioning it:
{"variables": {"browser": "Safari"},  "items": [    {"title": "Google",      "arg": "https://www.google.com",      "mods" {"cmd": {"variables": {"browser": "Google Chrome"}}}},    {"title": "Reddit",      "arg": "https://reddit.com",      "variables": {"browser": "Google Chrome"}}]}
Using variables

So you've set a few variables, and now you want to use them. Within Alfred elements like Arg and Vars or Filter Utilities, you use the above-mentioned {var:VARIABLE_NAME} macros. Very simple.

Where it gets a little more complicated is in your own code. First and foremost, {var:VARIABLE_NAME} macro expansion does not work in Run Script Actions (or Run NSAppleScript).

When Alfred runs your code, it does not use {var:...} macros, but rather takes any workflow variables and sets them as environment variables for your script. Using the above example again, Alfred would pass "https://www.google.com" to my script as input (either via ARGV or {query} depending on the settings) and it would set the environment variable browser to Safari or Google Chrome. How you retrieve environment variables depends on the language you're using.

Accessing environment variables in different languages

In bash/zsh, the variables are already in the global namespace. Just use $browser

In Python, use the os.environ dictionary or os.getenv('VARIABLE_NAME'):
import os browser = os.environ['browser'] # Or browser = os.getenv('browser')
In AppleScript, use system attribute:
set theBrowser to (system attribute "browser")
In JavaScript (JXA), use $.getenv():
ObjC.import('stdlib') var browser = $.getenv('browser')
In PHP, use getenv():

(Please see this comment by juliosecco on why you should use getenv() over $_ENV.)
$browser = getenv('browser'); // Or $browser = $_ENV['browser'];
In Ruby, use ENV:
browser = ENV["browser"]
Saving variables
 
NOTE: This section is out of date as of Alfred 3.6. Please see the updated version linked at the top of the post.
 
As amoose136 points out, any variables you set in a running workflow are not saved. They exist as long as the workflow is running and then disappear. Any Workflow Environment Variables will "reset" to their values in the workflow configuration sheet on the next run.

Generally, this is what you want, but sometimes you want to save a variable's value. For example, you might have an API_KEY Workflow Environment Variable in the configuration sheet. The user can enter their API key for the service in the configuration sheet, but you'd also like to add the ability to set it from within your workflow, e.g. with a setapikey Keyword and corresponding Run Script action.

WARNING: As of Alfred 3.4.1, Alfred takes several seconds to notice when info.plist has been updated by something other than itself. As a result, relying on altering info.plist programatically can be problematic, as Alfred won't notice the changes for several seconds (5–10 seconds is typical on my machine). If you update a workflow variable in info.plist and run your workflow again immediately, it is unlikely that Alfred will have picked up the change.

The Workflow Environment Variables are contained in the variables section of info.plist. Consequently, to update them, you need to update info.plist.

Regardless of which language you're using, you can call the PlistBuddy program to alter Workflow Environment Variables:
# Set a variable /usr/libexec/PlistBuddy -c "Set :variables:API_KEY \"ABC-XYZ\"" info.plist # Delete a variable (i.e. remove it entirely from Workflow Environment Variables) /usr/libexec/PlistBuddy -c "Delete :variables:API_KEY" info.plist
In Python, there's no need to use an external program, as it has the built-in plistlib library:
from plistlib import readPlist, writePlist # Read info.plist into a standard Python dictionary info = readPlist('info.plist') # Set a variable info['variables']['API_KEY'] = 'ABC-XYZ' # Delete a variable del info['variables']['API_KEY'] # Save changes writePlist(info, 'info.plist')
(Note: plistlib only works with XML property lists, which is fine for info.plist, but using PlistBuddy is generally more robust.)

Don't forget: any changes you make to info.plist only take effect the next time the workflow is run. This likely doesn't matter in most cases, but if you need a variable to be updated immediately (i.e. also for the current workflow run), you must also set it "live" using one of the methods described in the Setting variables section above.

 

Have you changed something since we've talked about it? 
Nevertheless i can now access environment vars in applescript via this:
set x to (system attribute "filename") That would be a set "{var:filename}"
 
Awesome that this works now tho! Or that i know this now haha, no workaround anymore

This is now in the 3.0.2 pre-release

OK,
please forgive me,
but you know, I'm italian,
and some kind of a respectful chatting is in my DNA,
 
I'll shut up now  

well, at least a little sign of  appreciation...
 
In have seen Vero and Andrew answering you like two little Gandhi...
 
please, try to be 'amazing' a little you too, just some little 'thanks' or 'regards' or 'cheers' or 'hi' or 'thanks' while you are posting your questions would be appreciated ( from me at least, but maybe I'm  too much sentimental )
 
    Giulio

http://www.packal.org/workflow/menu-bar-search

I tell you what, I'll make it so Alfred also recognises alfred3workflow the same as alfredworkflow in 3.0.2... but exporting from Alfred 3 I'd like to keep as always .alfredworkflow
 
 
The External Trigger will stay the same, all I'll be doing is adding a better way of calling the external triggers from within workflows using a specific "Call Workflow Trigger" object, avoiding AppleScript altogether

In most cases like this, the reason it works for some and not others is because the workflow has Alfred 2's directories hard-coded in it. If you still have your Alfred 2 directories (in ~/Library), it works. If not, it doesn't.
 
You probably just need to open up the workflow's source code in an editor and change any occurrence of "Alfred 2" to "Alfred 3".

If anyone is looking for another way to digest my earlier post, here are a list of actions that would need to be taken to proceed with the file extension change if no better ideas come up:
 
For workflow developers
Be very clear about Alfred 2/3 compatibility when you share your workflows, especially if you have existing users on Alfred 2 Until you intend to drop support for Alfred 2 users, do not modify and export your workflow from Alfred 3, not even to make minor changes. Your workflow will likely no longer work in Alfred 2 (see below). Once you drop support for Alfred 2, export your workflows from Alfred 3 as .alfred3workflow files For Andrew in a patch release of Alfred 2
Inspect all workflows before installing to ensure object-level compatibility (see below), show a message and fail to install incompatible workflows For Andrew in the next release of Alfred 3
Add .alfred3workflow file association Export workflows with .alfred3workflow extension (or alfredworkflow3 as others have suggested) Inspect all workflows before installing to ensure object-level compatibility to guard against incompatibility with future changes in Alfred (see below), show a message and fail to install incompatible workflows Make the major version of Alfred 3 accessible in an environment variable (per deanishe) For Dean in the next release of Alfred-Workflow
Allow updates to the .alfred3workflow file extension but only if running Alfred 3  
I'm not familiar enough with how Packal works or what Shawn is planning to suggest anything on that front.
 
Also, based on a diff of the workflows from the earlier example of changing the keyword in the Should I watch this movie? example workflow, I tracked down the specific part of the info.plist that makes this incompatible with Alfred 2. It is not the addition or modification of config keys and values, nor the change from real to integer for positions, nor the addition of the version key. Instead, the only change that makes Alfred 2 show that the workflow is incompatible are the incremented object versions:
  <key>uid</key>   <string>F8C5D133-7C4D-44F2-845B-FAE1568A09E7</string>   <key>version</key> - <integer>0</integer> + <integer>1</integer>  
This completely makes sense; the configuration for the Open URL and Default Web Search actions in this workflow has been updated and Alfred 2 does not have support for these versions. The extra/changed keys in most cases will not matter because Alfred 2 does not know to look for them so they will be ignored. On the plus side, this suggests that determining whether a workflow is compatible may be exclusively a matter of looking for any objects with unsupported versions. Such a test would be independent of "Alfred 2 vs Alfred 3" since the component versioning is already built in. There are already some components on version 1 which means that during the course of Alfred 2 development there have been changes that would cause workflows in the latest Alfred 2 to be incompatible with certain older versions of Alfred 2. It is not unrealistic to believe that Alfred 3 will have similar changes before Alfred 4 is released and would therefore benefit from this type of object-level compatibility test logic. We can't deal with those at the file extension or download manager level, so Alfred needs to know not to install them.
 
Unfortunately, it also suggests that any component that has been updated in Alfred 3 will cause an incompatibility with Alfred 2 even if it is not edited directly as shown in my earlier example. I think that's pretty much every component that you can put in a workflow. Any change to the workflow causes all of its objects to be upgraded to Alfred 3's version of each respective component. This is why developers need to avoid editing workflows in Alfred 3 until they are ready to drop support for Alfred 2, and if you choose to ignore that warning be sure to test every release in Alfred 2. 
 
 
Oh and Dean, shields.io has a good widget for download counts of GitHub releases (and plenty other interesting badges), here's an example URL :
 
https://img.shields.io/github/downloads/idpaterson/alfred-wunderlist-workflow/0.6.0-beta.3/total.svg 

Context is very important to this decision, there are many contexts in which the ability to distinguish Alfred 2/3 support is important.
 
Installing an incompatible workflow in Alfred 2
There may be many different ways that Alfred 2 could be updated to detect and refuse to install an Alfred 3 workflow. The easiest but least robust approach is to do nothing; use a new file extension in Alfred 3 so that new workflows are not recognized by Alfred 2. Surely some Alfred-3-only workflows have already been released with .alfredworkflow but it is still early enough for this to be a passable, if disappointing, solution.
 
Preferably, inspect the extension before installing as mentioned by Vítor. Not everyone will want to use the new file extension (e.g. third-party update manager does not support the new extension yet) and some people will just remove the 3 and try to install the workflow anyway.
 
Developers accidentally dropping support for Alfred 2
Currently, making any change and then exporting the workflow from Alfred 3 results in a workflow that is incompatible with Alfred 2. Try it with the Should I watch this movie example workflow. Exported from Alfred 2, updated to use a different keyword in Alfred 3, exported in Alfred 3, then installed back to Alfred 2 yields an incompatible workflow. That is quite unfortunate, developers will accidentally drop support for Alfred 2 by making innocuous changes in Alfred 3. 
 
There may be a few approaches to that:
Avoid generating an incompatible workflow in Alfred 3 unless an incompatible feature is used – I assume this is much easier said than done Track whether a workflow was Alfred 2 compatible and warn before exporting – again, not sure how simple it is to determine whether a workflow was Alfred 2 compatible Export with the .alfred3workflow extension as a cue to the developer that the workflow will no longer work in Alfred 3 – not the best solution but probably the simplest  
Update managers that use GitHub releases
Deanishe's Alfred-Workflow checks the workflow's GitHub repository for updates with the option to notify the workflow user when an update is available and to download that update. This is a tremendous feature to have in a workflow and Alfred-Workflow even supports pre-release updates for workflows like mine that always have new features in active development for anyone willing to test. GitHub releases are based on master branch tags which, at least for the case of Alfred-Workflow, are semver version numbers. A higher version with a single .alfredworkflow binary means there is a release available.
 
Most importantly for me, the workflow cannot download the .alfredworkflow file to inspect whether it is compatible or not. GitHub tracks per-release download counts and these have become very important metrics to me since it is otherwise impossible to know how many people are using a workflow; downloading a workflow is not only wasteful of the end-user's bandwidth but would also inflate download counts. This leaves us with a distinction that can be modeled in the metadata for the GitHub release.
 
Options here include
a release tag naming convention – not preferable since straight semver is clear and simple something in the release name itself – a decent indication to the user but it will get old to always include marker text in the release title .alfred3workflow file extension – clear to the end-user and  start a new repository specifically for Alfred 3 – for workflows that do not rely on GitHub issues, stars, release download counts, etc this may be an option. Of those options, #1, #3, and #4 have the benefit of blocking workflows released with an older version of Alfred-Workflow from downloading an update meant for Alfred 3. Furthermore, the logic allows consecutive updates to Alfred 2 and Alfred 3 workflows which is beneficial for any workflow with a large number of Alfred 2 users and a backlog of bugs to fix.
 
I am not sure whether any other workflow libraries provide automatic updates.
 
Update managers that use static version files
Alleyoop allowed developers to publish a static JSON file with the latest version of the workflow. I am not sure whether alleyoop is still supported, but if so there would probably be a few ways to handle the version compatibility. It is more flexible than GitHub releases since the JSON could be modified as necessary to denote Alfred 3 compatibility.
 
End-users downloading workflow files from the forums or GitHub
Assuming that Alfred 2 will be updated to not install incompatible workflows, there is not a huge risk here. Upon downloading a workflow and installing I would see that it is not compatible with Alfred 2. Bummer, but after this happens a dozen times I would probably just pay for the upgrade to Alfred 3. This incompatibility would be obvious without even downloading the workflow if it has the .alfred3workflow extension.
 
Integrated workflow updates in Alfred
I stumbled across this note from Andrew in red about supporting secure workflow updates within Alfred. This may not still be the plan, but it would be great to support GitHub releases. Packal seems like another sensible place to look for updates. I suspect that this is a very challenging problem since integrating into Alfred involves considerable responsibility to protect the user and validate workflows. An integrated updater would need a way to distinguish 
 
Packal
I think that Packal has far fewer limitations; without any changes in Alfred Shawn could add a checkbox for developers to select "Alfred 3 only" on a release and show a corresponding message on the download page to warn users. Of course it might be nicer to be able to detect that automatically when the workflow is uploaded, and even nicer still to be able to offer a version of the workflow for both Alfred 2 and 3 at the same time. Since Packal keeps all submitted workflows in a GitHub repository the .alfred3workflow might be preferable here since Alfred 2 and Alfred 3 workflow binaries could both exist at once.
 
Packal updater
Again a lot of freedom since the appcast.xml could be updated to distinguish Alfred 3 compatibility. Since the updater is standalone rather than integrated into a workflow like the Alfred-Workflow updater it does not have the same problem of making sure old versions do not download Alfred 3 releases. Just publish an update to packal-updater that respects the new Alfred 3 distinction and 
 
 
I don't suspect that many people will continue to develop Alfred 2 versions of their workflow after they make changes in Alfred 3. For awhile we will see bug reports about workflows not installing in Alfred 2 simply because the developer does not realize that even minor changes in Alfred 3 can render the workflow incompatible with Alfred 2. Alfred 2 use will decline over time as users upgrade but since it is a paid upgrade for most we can assume that it will not be an abrupt transition.
 
Of all the options I prefer the alternate file extension since it seems to provide a workable solution in every case. It is not a particularly elegant solution and is not a complete solution in some of the contexts described above, but like Vítor said, it seems to be the most robust way to handle these various problems.
 
If the new file extension is supported in Alfred 3 I still recommend making it the default extension for workflows exported from Alfred 3. Like I said on GitHub, it provides a consistent visible indication to the developer, the end-user, and any software that is unable to inspect the binary contents that a workflow is only for Alfred 3.

Hello!
 
I'm very new to Alfred, but I'm absolutely loving it.
I have to start-up Teamviewer and connect to a friend's desktop quite often, to help him with programming, so I was wondering
if I could automate the start-up and connecting process.
 
What I would ideally have happen is:
 
Type in 'John' (in Alfred)
Have it launch Teamviewer
Connect to the person using the ID and Password that are pre-determined.
 
Any way to achieve this?

Looking forward to your reply.
 
Cake.

Big +1 for this.
 
Had no idea it was even possible.
 
Actually, I'm rather astonished by how badly I need this considering I didn't think it possible 60 seconds ago.

You can get rid of the flickering in 3 by selecting "Don't close Alfred" on a connection.
But yeah, it's annoying that you still have to resort to AppleScript just to get Alfred to open the same Script Filter again.
External Triggers, the official solution to this scenario, are an awful UX dead end, from which there's no way back into Alfred proper.
Alfred still doesn't make the keyword used available to the workflow, either, so you have to hardcode the keyword in AppleScript.

This is straightforward to do with a workflow, but you need a Powerpack licence to use/create workflows. I dare say it'd be worth the price for this job alone.

To do this, first create a workflow.

Then add a Hotkey trigger (+ > Triggers > Hotkey). Assign your hotkey, and drag the Lightroom application into the list in the Related Apps tab.

Then add a Run Script action (+ > Actions > Run Script). Set language to "/usr/bin/osascript (AS)" and paste the following in the Script box:
 
tell application "System Events" to keystroke "Avalanche" Connect the Hotkey box to the Run Script action and you're good to go.

Repeat 29 more times for your other hotkey-text combinations. (You can copy and paste, then edit the existing actions).

Ding! Best of its kind. I highly recommend it.

Does that actually make it work on Alfred 3? I figured that one would need a lot of work because it messes around with its own info.plist a lot.
I haven't really got round to updating my workflows for Alfred 3 yet. I'm still digesting the new features and what I can do with them, and pondering how to alter the self-updating mechanism to prevent workflows running under Alfred 2 to update to Alfred-3-only versions.