1 of 1 people found this helpful
Could you not add this as a field to the department object. Then on setting a department on an employee record an editing rule fires which grabs the other field from the department object to a field on the employee [OtherObject].
On the department object I would make your new field a dropdown so you will require a new business object ot hold your validation list.
I hope this make sense, if you get stuck let us know.
Our employee object is populated via a feed from Active Directory. A department value comes across and populates the employee.department field, but it doesn't appear to have any relationship to the actual department object - is that typical?
I'd love to explore using the department object you described - since the object is currently full of out of the box data, is there a way to dynamically populate the department object with unique values that are in our employee.department field?
i will have a play with it later and let you know. I have a feeling that the department_valid field doesn’t populate correctly from memory and we can probably get round that.
So I tested an AD import this evening my department was created automatically:
Ad Import configuration nothing special just map the department field:
I would make the department field not required by ticking the box near to the use default setting just in case AD is not properly filled in (unless your going to check the logs regularly).
The employee record had a correct department_valid recid matching the department record. For you scenario you can use this relationship as follows to allow you direct access to the department record fields from the employee object:
DepartmentAssocProfileEmployee it is based on a many employees to 1 department 0..N:0..1 based upon Department_Valid = (other)RecId the other object being the Department table RecId
If you get stuck let let me know.
Thanks so much for your assistance and apologies for all the questions, working with objects in HEAT is very new to me.
From a request offering I'm able to access the employee object's field where our employee department data is synced to from AD (for us this is employee.MODDeptMarket, not sure why our implementation consultant didn't just use the standard department field). However the list contains duplicates.
In order to have a unique list of all departments our employees belong to, would I be correct to assume I need to utilize the relationship you mentioned above (Employee.DepartmentAssocProfileEmployee) to have it update the department table and store the unique values? Or is there a different approach to be able to extract the unique values to a request offering dropdown?
I noticed that in our Department object's department name field its the standard department names that seem to be out of the box like Accounting, Admin, Client Relations, Customer Service, etc. (all created in 2006 and modified in 2008).
Ok a fair few bits to work through here
So firstly is the MODDeptMarket field a text only or a drop down/Validation list? Ideally you would want to extract the full list of departments and then load it to the proper Department object or build a new validation list for the departments and remember to set a unique key to prevent duplicates in future.
Once that is done we can map the existing field to the new field or to the preferred Department field (bare in mind that there may be other functions attached to MODDeptMarket that should be considered).
The screen shot is that your current config or something you are proposing? If proposing it will not work as that usually works when a relationship is create and there wont be that currently I expect. We may need to run some quick actions to copy the data around properly if needed.
I hope makes sense, if not you know where I am.
The Employee.MODDeptMarket is just a text field which accepts anything AD drops into it.
I've setup a pick list for the departments (GeoffDept). Within the picklist settings I don't see a way to set a unique key to prevent duplicates in the future - how would I go about doing that?
If working on the dept object would provide more robustness or flexibility moving forward I'd be happy to go that route rather than a pick list - the key is I need the list to eventually be dynamic based upon the unique values in the Employee.MODDeptMarket.
The screenshot was just something I was proposing.
Thank you! Ok so I'm all squared away with that part.
How would I map the existing field (employee.MODDeptMarket) to the department.DepartmentName field?
Couple of options:
- use a Quick action to set the department field = MODDeptMarket then highlight the records to update and run the script. If you have lots of employees then you could build out a workflow that uses the run for search block. It uses a saved search for example where Employee RecId is not empty an then call your quick action to copy the fields.
- Update the LDAP/AD import to set the department field, delete the AD Sync data and reimport all records
I will mention the SQL script but bare in mind it is not supported should anything go wrong....backup database, testing staging etc. etc.
Again if you need more steps let me know.