VBScript 1.1.0
The usual way of working with persistent variables is most likely from within a call routing script. From v1.1.0 the persistent variables can also be used outside of a call routing script, i.e. in a standard windows scripting file (.wsf) or an asp web page.
In these cases the persistent variables switch their default Scope from User to Global to reflect the fact, that they don't have access to a SwyxWare user id, and therefore can't use the User Scope completely by themselves.
If for what reason ever you need to access a persistent variable in the user scope of a certain user from outside a call routing script, you need to specify the SwyxWare user id belonging to that user and switch the scope to User:
<package> <job id="set_variable_in_user_scope"> <script language="VBScript" src="PersistentVariables.vbs"/> <script language="VBScript"> Dim MyVariable Set MyVariable = new PersistentVariable MyVariable.Name = "Welcome" MyVariable.Scope = SCOPE_USER MyVariable.UserID = 15 MyVariable.Value = "Beep.wav" Set MyVariable = Nothing WScript.Quit </script> </job> </package>
If you save the above code into a text file and name it SetAnnouncement.wsf you can call it directly from the command prompt: (the PeristentVariables.vbs file needs to be in the same folder!)
C:\PersistentVariables> SetAccouncement
The above example demonstrates the usage of persistent variables in a standard windows scripting host file (.wsf).
There are many way to figure the user id of a SwyxWare user:
- Assuming you are accessing the variable also from inside a call routing script you can simply take a look into the PersistentVariables table and take the user id from there.
- You can also trace it into the server trace file from within a call routing and read it from there.
- Use any of the SwyxWare APIs (Server Script API, Client SDK, ConfigDataStore SDK, Powershell) to obtain it from SwyxWare.
- ...
Please find a complete explanation of the usage of persistent variables outside of call routing scripts here:

By Tom Wellige