I have the following use case. From looking on User Voice and seeing @EuanGamble comments I'm hoping this might be possible in the new data connectivity control.
(This is also something that I can currently do on premise with nintex forms enterprise for sharepoint)
At a school we would want a parent (has user account in our AD) to login into the form.
Knowing the username we take the username as a parameter to a stored procedure, which returns a list of their children. (typically studentID as value and Student name as the display value).
This would allow the parent to pick their children from a defined list.
We could then further take the studentID from the selected item on the control as a parameter on the second control which would return regarding the student (eg school year, house, etc).
While I have mentioned SQL, I guess we could make this work with a web service as well.
@EuanGamble Would this scenario be feasible with what is on the development roadmap for NWC forms?
That's a really good use case, Gavin. So, you would still want to allow parents to log into Nintex Workflow Cloud using AzureAD, pass the user identity to a web service and return some data (e.g. student and student details). Where would the data be stored? In AzureSQL?
I will share this use case with the team.
Hi @EuanGamble ,
thanks for replying.
Initially I was thinking of just using the MS SQL database connection and using stored procedures, same as the SQL control on nintex forms enterprise for sharepoint.
Bit of background for school environments. Lots of schools have sharepoint on-premise. With internal AD users accounts for staff, students and parents. Moving to office 365, sharepoint online does not work for parents as education licensing only provides staff and student licenses. It's too expensive to license sharepoint online for parents. So that rules out Nintex for Office 365 for parent forms. (Still good for staff and student forms through).
Naturally NWC with authenticated forms as we still have the sync'd parents user accounts into AzureAD is a good fit. Also typically each parent has their own logon, so there is a 1-many relationship between student account and parent accounts.
Not too many cloud based student information system so that is often a SQL on-premise system.
We could potentially sync data to an AzureSQL instance but that has it's own nightmares of keeping data in sync. Connecting through to the on-premise SQL directly would be preferable.
Coding some sort of mid tier web service would be possible to interface between on-premise SQL and the form control but would really prefer not have to write code and then host it somewhere.
From the end user experience we see common concern. As a parent you know who I am by my logon. You know who my kids are. Why everytime I fill out a school do I have to type this information in. Then from the school perspective the received string data would need to be data matched against a student record.
So need the data connectivity to make the forms a lot smarter.
Hope this helps explain the pain points and thank you for passing on to the team.