I think it would be handy to have the ability to create custom variables for both cross-tenant and tenant-specific cases.
One example of where this could be useful, is if you set a custom “$DEMUserName” and “$DEMPassword” variable for each tenant, then you could have a single cross-tenant deployment of Join AzureAD with the fields set to those variables and maybe a tenant tag to identify AzureAD tenants.
Another thing this could be useful for is to overwrite things that might not usually be changeable. For example, someone mentioned the form factor short names not being changeable right now, but what if you could overwrite them with a custom variable for only the cases that you need it?
I would also like to see this. We have a ton of tools in our standard toolset, if we had a tenant level custom variable we could put that customers unique value in their tenant and map the software at the cross-tenant level. This would be SOOOO much easier than what we are doing today. Right now we have to create a separate deployment for every single tenant for every single tool.
1 Like
This would be helpful for the SentinelOne deployment where we have a shared tenant key that expires every 30 days. Updating the one variable would be preferred to updating each client’s deployment.
There are a number of cases where we need to reference Org IDs in other systems that don’t currently have full integrations (IT Glue, NinjaRMM). It would be extremely helpful to have this so we can create one cross-tenant deployment, instead of one deployment per tenant.
This is a feature that would be incredibly helpful in the configuration of software per org without the need to create per-tenant deployments.
I am running into issues where variables have to be specified in the parameter portion of a deployment so that only 1 deployment is needed (instead of one deployment for each tenant). i.e we specify a $companycode when deploying a software every time we deploy as the companycode can change between tenants.
It would be nice if there was a section in ImmyBots similar to Licensing where we can specify Tenant-Specific variables and name them for use in a script. i.e If i want to deploy Chrome but it needs a Tenant-Specific Install Key I would like immybots to look at the tenant the PC we are deploying to is in, find the $ChromeTenantKey in the tenant variable list, and pass through the value. this would eliminate the need to make 12 seperate deployments for 12 companies or specify parameters of what the $ChromeTenantKey should be every time you deploy. This would be invaluable as not duplicating work 12 times over creating deployments or specifying a key every single deployment would save some time in the long run.
Here’s the problem. When you create these variables it creates confusion for your techs because they will see that empty field and wonder if something is supposed to be there.
Actions will fail inexplicably and you have to just know that the task relies on some random global variable somewhere versus forcing you to put the all the data in in a single place, the deployment.
For SentinelOne you should be giving us a single API key and targeting it to your PSA for customers who pay you for it.
For the Chrome key, create a Tag and tag the tenants who are supposed to get it and create a deployment against that tag.
For IT Glue and the rest of the half implemented integrations I would rather focus our efforts on converting them to proper integrations so we don’t need to build a feature that will lead to further confusion.
I’m not seeing exactly what you’re saying here Darren - literally every other tool uses custom variables without issue. Techs aren’t maintaining them - the system admins (me) are, so if deployments don’t work I know why. It’s already engrained into us that some deployments require tenant-level variables. There are just too many use cases for them to not have them, and not having them causes more work otherwise that could be avoided, turning what could have been cross-tenant into a tenant level deployment. Isn’t it better to have more cross-tenant deployments and less tenant deployments?
Maybe having it implemented via JSON (either exposed to us or not) might be a simple way, where the tenant has a JSON block that can be referred to for custom variables? I realize you’re not a fan, but I think a lot of us don’t fully understand why.
Sure you might understand it, but I’m looking at this from the perspective of the next guy and long term management at large. If you have custom variables that only exist in your instance and you want to share your task with someone else, you will have to tell them which variables they need to configure. Whereas currently everything is self-contained in the Task, making them portable.
I hated when I would get an export of someone’s labtech script and then it would create custom variables for all kinds of stuff that I already had custom variables for in my labtech. If I rework their script to use my own, then when they update it to fix a bug, I have to rework it again.
Often times in Labtech we were all creating custom variables for things that they should have had built into the schema but they didn’t keep up with the times. AzureTenantId for example. So if there are things like that you believe should be exposed for everybody, I would be happy to add them as built-in variables. But whatever it is you need a custom variable for, likely someone else and perhaps the majority of our users, also need it.