Storing attributes in HR applications

AnirudhKumar
Mega Sage

Hi ServiceNow folks,

 

Often times in HR implementations several attributes are tracked in the process. Of course, these are beyond what is provided OOB - from the HR Profile table and from the HR child classes. The need becomes greater when clients say they want to report on these attributes. 

 

To give a generic example, imagine SAP sends ServiceNow an email containing a ton of timesheet information related to an employee and ServiceNow needs to make use of the parsed attributes from the email. Where would you store all these ad-hoc data? 

 

Looking for a scalable solution (and examples of how you handled it in the past) that is beyond just creating custom fields on the case or creating a new table altogether.

1 ACCEPTED SOLUTION

Uday Damaraju
Kilo Guru

Hi @AnirudhKumar  - 

From overall architecture perspective, I would challenge this requirement because SN cannot be treated as authorized system of record neither for HR profile data (may be it is SF) nor the timesheet data (you said SAP)- SN is only meant for HR Case transactional data- in such a scenario why would I take effort/risk of bringing it into SN from different sources, maintaining it and then report- WHY?

If it is inevitable - can think of 2 options: 

SN HRSD solution or data model is not designed to accommodate timesheet info rather SN's SPM/PPM solutions do accommodate the same. So - its worth checking if your org is leveraging SN PPM solution for timesheet info of an employee- if yes bridging the HR Profile, case and the PPM table would be a way to go in my opinion.

Assuming, you SPM/PPM solution isnt being leveraged currently- you only have HRSD subscription model- I would incline towards leveraging a concept "Shadow table(s) with DocumentID" - Note: in this case Shadow table(s) is/are a custom table(s) that consume custom table quota that comes with respective subscription you got. This way way you could store the data and leverage for reporting purposes as well at the same time I avoid cramping some 50 fields (timesheets relevant) into HR Case table. 
1. Create a custom table; Ex: u_hr_external_transactional_data
2. This custom table uses a Document ID field to link back to any record (Case, HR Profile...) and has other  fields that you want to capture
3. You can capture&store timesheet info from SAP without making HR Case table heavy
4. Report on custom table & can dot walk to Case/HR Profile as required
5. Make an effective plan for maintaining the transactional data on this custom table (# of records, retention periods etc.)
 
 "Hope that helps, if it does, mark it as helpful & accept the solution"

 

BR, UD

View solution in original post

1 REPLY 1

Uday Damaraju
Kilo Guru

Hi @AnirudhKumar  - 

From overall architecture perspective, I would challenge this requirement because SN cannot be treated as authorized system of record neither for HR profile data (may be it is SF) nor the timesheet data (you said SAP)- SN is only meant for HR Case transactional data- in such a scenario why would I take effort/risk of bringing it into SN from different sources, maintaining it and then report- WHY?

If it is inevitable - can think of 2 options: 

SN HRSD solution or data model is not designed to accommodate timesheet info rather SN's SPM/PPM solutions do accommodate the same. So - its worth checking if your org is leveraging SN PPM solution for timesheet info of an employee- if yes bridging the HR Profile, case and the PPM table would be a way to go in my opinion.

Assuming, you SPM/PPM solution isnt being leveraged currently- you only have HRSD subscription model- I would incline towards leveraging a concept "Shadow table(s) with DocumentID" - Note: in this case Shadow table(s) is/are a custom table(s) that consume custom table quota that comes with respective subscription you got. This way way you could store the data and leverage for reporting purposes as well at the same time I avoid cramping some 50 fields (timesheets relevant) into HR Case table. 
1. Create a custom table; Ex: u_hr_external_transactional_data
2. This custom table uses a Document ID field to link back to any record (Case, HR Profile...) and has other  fields that you want to capture
3. You can capture&store timesheet info from SAP without making HR Case table heavy
4. Report on custom table & can dot walk to Case/HR Profile as required
5. Make an effective plan for maintaining the transactional data on this custom table (# of records, retention periods etc.)
 
 "Hope that helps, if it does, mark it as helpful & accept the solution"

 

BR, UD