Collect Password but show field as invisible when task completed


Badge +9

I'm collecting username and password from the help desk when a new account is being created on a certain system so that the workflow would send an email to the user with the new username and password.

I'm creating a new content type and collecting this information with no issues, the problem is I only want the password to be sent in the email through the workflow and I prefer not to have it visible on the task form when the user sees the workflow history data (when the task is completed). 

Is that possible?


3 replies

Badge +8

Hi Christine,

As no one has replied on this one, I am assuming you still are looking for options..

I could probably think of the following 3 ways depending on which could be the easiest option for yourself.

1 option ] In your TaskForm the single line text box (which captures the user input as password) you could change the Advanced settings -> Password = true

201643_pastedImage_1.png

With this the password would be "masked" when you view via the workflow task form (once it has been action-ed by the user). The caveat to this is you could still go to edit source (of the completed task form) and in the source you could see the password. So this approach is not completely fool proof but for a casual user this might be okay.

Further this is the simplest approach and I believe the password (which may be generated by the windows user) generally would have "the change password at next logon" checked so hopefully the password would have been changed by then. Its not the best option but the most simplest.

2 option ) After the approval and sending of the notification you could query the workflow task (or start another workflow to be sure the data is committed) and query the task and remove the password from the form element (column name is form data) of the workflow task. Its generally stored as XML so you would have to be careful only to remove the password bit or the entire task for will not show up. (Not sure if you even want to view the task form after the mail has been sent or better off delete the workflow task when the task is completed - if auditing is not key in your organisation). Again if the workflow does not have access to its own task form, you would need to spin off a secondary workflow to do the cleanup bit.

3 option ) In this you might have to take a different approach and separate the password capture from the notification bit. You could create a new list just to capture the password /username and security trim it depending on who can edit etc. You could then run a new workflow which just reads this list and sends the password to the user. This would ensure that your password list is blocked from all the users and only elevated privileges (like the workflow) could read and send it.

Regards,

Shrini

Badge +9

Thanks Shrinivas Naik‌ for the detailed explanation and options. I'm inclined to try option 1 for now (just because the amount of time I have left to complete this workflow). Also, it just happened yesterday that the stakeholders changed the requirement for the permissions on list item to be only viewable by the person who requested it who is mainly the person getting the email with the password. (and of course only IT people have full control). Since the users are actually just test driving Nintex/workflows/approvals, they are so eager now to go back into the task forms and see what is actually been tracked on each step. So to avoid all the anxiety of having an "initial password" display in clear text, along with the granular permissions added on item level, I think option 1 would be perfect. I'll give it a try and let you know how it goes.

Thanks again!

Badge +8

Hi Christine,

Glad could be of help, Please also be aware of granular permissions on SharePoint when we try to set item level permissions on SharePoint it causes performance issues once the size of the list goes very big.

Just to keep that back of you mind if the requirement is for item level permissions .. you could still archive the results though.

Best practices for using fine-grained permissions in SharePoint Server 2013 

-- Please can you mark as answered if it solves your problem as it might be helpful for people searching for similar questions.

Regards,

Shrini

Reply