Client Support
Showing results for 
Search instead for 
Do you mean 

Securely storing date of birth data and use as a trigger for disposal

SOLVED
Go to Solution
Esteemed Contributor

Securely storing date of birth data and use as a trigger for disposal

Hello

 I am looking for some assistance regarding the best location to store date of birth data securely within TRIM and how to then use this data for retention and disposal triggers.

 Firstly I know that each location in TRIM can have DOB data applied, however this information is open to all who can view location information. Is this correct?

Therefore I am looking at instead creating an additional field attached to each internal staff member with this DOB data and in HP RM using access to prevent most users from viewing this data.

 I believe this is doable in HP RM 8 but not TRIM 7.34

 Even when I have DOB as data against a location, can I use this data has a disposal trigger for records within TRIM?

 For example

 Disposal trigger: 100 years after DOB.

What may be tricky is that the DOB data is against the location not the record (although the record and location are linked by means of client titling)“

6 REPLIES
Occasional Advisor

Re: Securely storing date of birth data and use as a trigger for disposal

What would be ideal is to have metadata validation to SQL tables. For example, the metadata field could be the Employee Number. When the metadata is displayed it also displays the Employees Name and other information held in the Employee SQL table. If this was able to be done, then the Employee Number would be able to be used to link to Employee table fields such as “Employee Termination Date”. That would be an ideal date for retention and disposal.

Having diferent SQL Views of the SQL table would ensure that DOB is only in the view where R&D processing is performed.

An additional benefit would be when you go to the pick list of employees you would see the Employee’s Name as well as their number displayed in the pick list (as it would be a view of the Employee table) and filter on name to get the correct Employee Number.

Visitor

Re: Securely storing date of birth data and use as a trigger for disposal

Hi Joshua

Assuming this question relates to personnel records, one solution would be to add a DOB field (Additional Field) to the Personnel Record and then configure your triggers to use the Additional Field when sentencing the personnel records. These records should already be restricted to HR staff, however if you’re trying to save the DOB information elsewhere, on records or locations that are visible to a wider range of staff, this would be more difficult to secure.

Hope this helps!

Esteemed Contributor

Re: Securely storing date of birth data and use as a trigger for disposal

Hello

DOB is related to personnel records. I don’t want DOB individual added by each user (and these records won’t have a folder) so I might just need a separate process to add DOB data (using an additional field) to records post creation

Honored Contributor

Re: Securely storing date of birth data and use as a trigger for disposal

In HPRM you can set "view" and "modify" value permissions on an additional field, soething that didnt existing in 6.x or 7.x

 

This permission would apply regardless of the type of Object the field is associated with, so if your DOB field is associated with Record and Locations and you restrict view to "Human Resources” then only "Human Resources" can see the date of birth field on Records and on Locations.

 

So if you want DOB to be a Mandatory field this would meant that either only "Human Resources" can create the files, (or "Human Resources" would have to update the files after creation to add the DOB)

 

A trigger has to work off a Record field, so if you want the DOB of a Location to be the trigger then you would have to have some mechanism to identify the location on the record (using a Location additional field) and during file registration have the person registering the file copy the DOB for that location to the record. Again if the view permission of the DOB is Human Resources then Human Resources would have to do that

 

You could have a background tasks that updated the DOB of a new record using the DOB of a Location that associated with the record but that would involve writing code/scripting. In that scenario the person registering the file would not need to have view permission to the DOB additional field.

 

 

Esteemed Contributor

Re: Securely storing date of birth data and use as a trigger for disposal

Thank you

 

Yes this is exactly what i need to do i believe. Thanks for the comments,

Honored Contributor

Re: Securely storing date of birth data and use as a trigger for disposal


Rich_Kid wrote:

....

 

You could have a background tasks that updated the DOB of a new record using the DOB of a Location that associated with the record but that would involve writing code/scripting. In that scenario the person registering the file would not need to have view permission to the DOB additional field.

 

 


need to clarify that statement as I was assuming the process would be something like an event processor addin (which is the way I would do it ...) but it could be a record addin that ran in the Client. In that case the user registering the record would need access to the DOB field. 

//Add this to "OnDomLoad" event