HR cases and transfers
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-07-2017 02:38 PM
I'm looking through the HR case management application and came to something that i'm not sure what the specific purpose is.
We're looking to implement HR and the part of transferring cases from one HR service to another is unclear.
- What is the purpose of this? Are the directly tied to an assignment group?
- Is it wise to remove this design?
- What's the upside/downside of using these services?
Our primary concern is that most of the cases would be sent in via email. Everything would be automatically set as General. That would require a transfer of almost all cases coming in.
- What would be a good option or alternative if we didn't want this to occur?
Second, most of the responsibilities would be with the same group of people. I think we're looking to have it function more like incident so the transfer process really wouldn't make too much sense if it's a method of assignment.
- Labels:
-
Case and Knowledge Management

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-07-2017 05:11 PM
Hi,
Please note that HR module works differently from rest of ITSM modules.
Every HR case type ( e.g general, employee relation) is tied to different tables.
Transfer case happens in below scenarios
- When existing assignment group determines that case belongs to other case assignment group for different HR Service.
- It's not best practice to remove design, You can train resolver to use transfer case functionality.
- Transferring case since current HR Service , topic category and topic detail is not correct for current case.
You can handle routing of HR cases in inbound email action code script.
Regards,
Sachin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎11-08-2017 07:16 AM
Thank you.
I think the transfer process is a little too much for our organization as most of them would handle most, if not all, of the duties in each COE. Since they're different tables, I'm assuming this is for security reasons.
With inbound actions, are you suggesting that each COE has its own email address for proper assignment? If it is, I'm not sure how practical it would be. I think if we can solve for this, it could alleviate our concerns.