There are a lot of bugs/nuances in secrets management. @Ali Syed (NS DevTools QA) @Carlos Olivares (NS DevTools PM) These are refraining us from using secrets management because of the instability of this feature. Please fix these ASAP. Please do update help center with exact details and examples 1. help article here says to use

secret: '{custsecret_<id>}'

but this doesn’t work. We need to use

secret: 'custsecret_<id>'

2. Updating the secret, there are no validations for password. I can submit with empty password on updates 3. updating a secret is not updating the secret in the installed accounts. I tried logout, deploy, uninstall-deploy 4. Using a secret with createSecretKey only works for UTF_8 encoding. Any other encoding throws an error about byte size. It works in an online tool 5. The code sample here uses hex code as encoding and a guid. Using the exact code throws an error. 6. There are no code samples on how to use a secret correctly for different encoding standards 7. Using the test accounts field on Secret is deviating from using CLI, this would invite a lot of bugs which could never be caught on QA/stagign and impact our customers. 8. the help article here just mentions that we need to add a reference for the secret, there is no mention on test accounts and nothing 9. Allow access to Scripts field needs the scripts to be seperated exactly with comma. If there is a space after comma it wouldn’t work. Eg: ‘a,b’ works ‘a, b’ doesn’t update

Hello @Uma Kanth, thanks for providing so detailed request. I will make sure that the responsible team go over the pain-points you are enumerating and find the right solution for it. From our side (@Ali Syed (NS DevTools QA) and me), we are limited to provide support for this case (we are focused on the tooling and SDF side), of course if there is something we can elaborate, we will... however this request is something we can not address ourselves. The best way to provide official visibility for this, is to create an issue so it gets into the right place (I will transfer the 9 points to the team directly anyways)

you may actually want to get the secret key examples working with addSecretKeyField first

@battk I’m not using a form. I was using a restlet. I tested the key lengths by generating it with an online software. Encryption/decryption also worked fine with those keys. But the same keys throw an error with secrets management apis. The key given in the help center also was not working. Even though the encoding is provided, it was not able to decode it properly and hence the bytesiz errors.

i know from experience that the guids generated by a secret key field work

Message delivered to the responsible team, at any case, if you want to make sure this is tracked somewhere, file an issue (this belongs to SuiteScript team)

Eeesh

We were considering this as well for our suiteApp. As it is not that stable, we are not thinking of using this in production as this could cause problems. Once this is stable, it would be a simple change in the SuiteApp.

I am saddened

FYI, NS told me that the updates to a custom secret made in the source account is not immediately reflected in the destination accounts. It takes about an hour to update. i.e, they upadte it on a schedule. This poses multiple issues where the source and destination are not in sync and we don’t have control on the deployment and a script using custsecret could be using out-dated infor and could result in a lot of issues. NS has accepted this as an enhancement, If anyone else would like this to be fixed, Could you please vote for this enhacement. As without this enhancement Secrets Management is not usable in production.

Enhancement # 633202

Summary: SDF > custsecret Object Changed in the Source Account > Ability to Run On-Demand Synchronization for Target Accounts