Form requirement nuanced trade-offs with proper relational structures
I have two related questions! Someone suggested using grid edit reports on my forms for a more all-in-one parent-child editable comprehensive form. That's not working at least on my end -- has anyone had grid reports be available within a form? I'm reorganizing another section of my app for a division that hasn't moved over to my current setup yet. In their legacy setup, there is currently a one-form-fits-all, which requires many things based upon the service level they rendered. We're moving to a "Clients", "Cases", and "Service Calls" -- which means I no longer can require things at the Client or Case level based upon the extent of the service call..... is this just a trade off I have to make? I'm concerned people might not go back into the parent record and update with additional information as it's received in this new setup (and hence why the grid edit would honestly be a fabulous option -- bring the Service Call record right onto the master record and edit it all from there).
Strange Problem with a relationship and record picker.
I have a long standing table, Core Returns, that has a lot (too much, but just blame Admins long retired) of information. There is a field that gets filled in at a point well after the record is created, automatically, through updates. That part is working fine. I recently added another table, HVNE PO's, as part of a different project that does share some data with the older table. There is a reference to an 'Equipment' number. That number is the Primary key in the HVNE PO's table. I have it set where the HVNE PO's table is the parent table and Core Returns is the child table as that same equipment number can and does crop up in the Core Returns table multiple times. The Equipment number, however, does not necessarily exist in both places. The Goal is to allow a User to look from the Core Returns table and see if that Equipment number exists over in the HVNE PO's table. The users' decision about what to do next is impacted by this. So that's what I want. My Relationship is like this: HVNE PO's is Parent, Core Returns is Child. Equipment is the Text (Key Field) in HVNE PO's. Ret_Equipment is the Text (Reference). The reports display everything as expected. Now, in the form to look at records in the Core Return, when just looking, it displays as expected, but when you go to Edit the record, Ret_Equipment displays a date and gives a drop down with completely unrelated information. If I don't touch that field, make other changes that I need to make, when I return to the report or the eyeball view, it's fine. The problem is that I may occasionally need to edit that field and now it's all screwed up for that workflow. I have a gut feeling that it is a simple setting somewhere, but for the life of me I can't find it.
Security Group Management
I am working on a new application which will act as our recruiting/employee management system but will not be an HRS platform. This application will handle all the activities that occur before they become an employee. In our IT environment we use security groups to help provision employees into groups that grant them access to data, programs, digital locations, etc. These security groups are rule based and are used to examine an employee's Company, Department, Job Title, and Office Location to determine their group membership. I'm trying to build an interface in QB which would display to the user the various security groups the employee will be placed in based on the selections made in the fields referenced above. An employee will be in at least 1 group but could be in multiple groups and we currently have about 175 different groups configured. I considered creating a single formula field in the Employees table, called Security Group, which would hold all the various security group rule formulas, but that felt a bit too much to manage. I also considered creating individual formula fields, 1 for each security group, but that too feels too much to manage. I have also considered creating a Security Groups table which has 1 row for each group. The table would include: Group Name, Group Type, Group Description, and Group Rule. The group rule field would hold the actual QB formula that could be used to evaluate if an employee fits into that group. But I'm at a loss as to how to connect the Security Group table with the Employees table so that Employees can benefit from the group rule formulas it holds. Again, an employee can be in 1 or more security group. Looking for any suggestions on the best way to set this up so that the management of the security groups is nominal (we may need to create more in the future), so that we can see which security groups an employee would be a member of, and so we could see all the members of each of the security groups.
