Hi,
Get Orchestrator asset: Get Orchestrator Asset does not work with assets of type Credential.
Been getting this error while getting assets type of credentials from config, What is this error about, and how do I sort this error?
There is a separate activity Get Credential for credentials. I suppose this is the solution here?
1 Like
Hi , @Vijaylakshmi_2
new System.Net.NetworkCredential(string.Empty, securetoken).Password
If you want to credential you can use this code
You can’t put credentials asset types in the config.
Hi,
I have passed the asset file in the config, still it’s the same.
As I said you CANNOT use credentials assets in the config.
1 Like
You can try to put the credential type asset in Settings sheet instead of Asset Sheet of Config File. And use ‘Get Credential’ activity to get the credentials.
That exposes to password to simple logging. Your security officer will kill you. DO NOT DO THIS.
I strongly suggest you simply stop managing your assets with a config. There is no benefit.
Just use a get asset or get credential activity directly in a workflow as and when you need it.
1 Like
Just go through the REFramework documentation. Config Asset sheet is only for non credentials assets.
Thanks,
Ashok 
Benefits: portability, ease of management, ease of moving from QA to prod, people don’t need access to Orchestrator to manage a config file, config file can be included with template, etc…
None of those things are reduced by skipping the cumbersome config.
For example, take this process, when I move from QA to Prod the Orchestrator will validate if the assets exist or not for me. Something not possible if you use the config to manage your assets, it will just fail after you run it.
Your comment on a user not needing to access the Orch to change an asset value makes no sense. If that were the case you are basically skipping any asset or credential management altogether and storing everything in the external config, which makes zero sense for credentials and just makes the credentials harder to manage because of the external dependency. There would be nothing you could change in the config that doesn’t require a corresponding activity in the Orchestrator and I don’t know why you’d want that.
Regarding using them in templates, directly using them in a workflow doesn’t in any way hinder using them in templates and has all the benefits of above, it also means if you don’t use them they are easy to remove. In a config Excel its much harder to get an overview of if an asset specified there is even used.
Regulations and compliance. Separation of duties. External credential management system. Developers aren’t allowed to do much in the production system and there is no way around this…except a config file.
I can stand up a fully functioning automation complete with queue, logging, metrics recording, exception handling, etc in about 5 minutes because the config file is standardized and I only have to create one Asset (that points to the config file) and the queue. I can copy the config to production in about 5 seconds. I can make a quick copy of the config during development/testing. Don’t need asset validation when everything is standardized in a template.
Doesn’t hurt anything if it isn’t. And I don’t have dozens of Assets to manage for every automation, which is especially painful due to Orchestrator’s poor interface. And as far as I’m aware, there’s nothing in Orchestrator or Studio that will tell you if an Asset is not used in your code.
Thats easily managed by either permissions in the Orchestrator, or connecting your credential manager to one of the many many credential stores. Any compliance person worth their salt will prefer something that has a very clear audit trail and easy user level permissions over an Excel. So there are many ways around this, with the Excel being one of the worse options.
I can do all that and its easier, since I don’t have to worry about the config and all my assets are already ready there too. So if and when I need to change any assets its smooth. I don’t know why you keep acting like using assets like this means you cannot use them in a template… you can. For example in my framework part of the loading uses an asset to set the runtime browser, its in my template, and easier to understand the usage of vs an Excel.
So what happens when you add a new asset that isn’t part of a standard but because its needed for this specific process? At that point you need to remember to create that asset in all subsequent tenants, which inevitably goes wrong sometimes.
I already showed a screenshot showing this. You just won’t see it if you are loading assets from an Excel or other method instead of just doing it directly.
Group permissions, group policies, etc are plenty easily audited. And well known by IT staff whereas Orchestrator isn’t.
Look, what works for you works for you and that’s great. It doesn’t mean it’s the only way to do things, nor that it’s the only right way. Often there are things going on you may not be aware of that make one solution better for someone else than you think it is. Saying there’s no benefit to config files is simply wrong, as I have illustrated. In many situations there are benefits, and I listed some of those situations and benefits. The end.
Fine, but you are also pretty close minded on the topic Paul, many things you say as if they are facts are easily countered, as I did with most points, leaving us I feel with only the auditing part as a contested issue. I still don’t agree on that one since if your auditor ignores the Orchestrator altogether they have a huge blind spot, and if they are already in, the auditing is stronger than Excel, but what works for you.
The reason I put it in those strong terms of ‘no benefit’ is because people have been sleepwalking into the same old ways of working without thinking about why they do it and I am challenging that. Perhaps there are indeed niche cases that require you to not use assets at all, but then its a moot point and a distraction. If you use assets, skip the config is good advice for 95% of cases.