This can end up being complex or not so complex, depending on the business requirements you are trying address, the levels of smarts you need in the system, the flexibility for further types of account setup activities in the future, other types of employee things you could be doing such as employee termination, how intuitive you need the system to be, how maintainable you need it, etc...
I have seen a few different organisations take different approaches for this, some with more success than others. As others have suggested, there are a few approaches such as wizards and control panels. Another option is having a table field listing the different areas of data, which opens a corresponding dialog window to capture that data. SRM is always an option, although some of the same challenges may exist. If you haven't done this already, I suggest spending time clearly understanding the business requirements, then designing a solution to meet these requirements. If the requirements are simple, the design can be simple and the end solution simple. If the requirements call for lots of flexibility and complexity, then these need to be addressed in the design, and then built into the solution. Even when replacing an existing solution there is value in exploring the requirements, business needs change over time and what the needs where when the previous solution was built may be quite different now. Sam From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Brien Dieterle Sent: Thursday, 20 November 2008 10:44 a.m. To: ARSList Subject: employee setup form best practices? ** I'm building a custom form to handle changes for new/existing employees-- things like account creation, email setup, shared group folder permissions, new computer setup, office phone setup, furniture and even name changes. I am duplicating an existing form from a different system that did all of this on one form using dynamic html to hide and show fields as selections are made. I was wondering if anyone had any suggestions as to how to handle a big form like this, or if this is the wrong approach entirely (should it be split up into smaller forms?). My first problem is that the form starts with a basic information gathering: Select employee type: New or Existing. Now, depending on what you select there are different fields available to fill out (by hiding/showing different page holder tabs). The pain comes when certain fields are required only when a certain choice is made. (If you select "New", well, you better provide a first and last name, right?) It doesn't seem like you can change a field to be required on-the-fly using "change fields" (is that correct?). So I am left with leaving them blank and using filters to check the required fields, or using activelinks to set the unneeded "required" field to bogus values like "N/A". Not a pretty picture. My gut says when something is difficult it is probably wrong. Active Links Guides look like an idea but this needs to be web-based (ALGs don't work on web?). Thanks for any tips! ARS 7.1 patch 003 MS-SQL Tomcat Brien __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
