If you are in the K19 HR Fundamentals class, please post your questions here using the COMMENT link. Classroom staff will be monitoring this conversation during class on May 5-6, 2019 and will answer to the best of their ability.
Is there a bulk case close complete. Example 1000 payroll cases are made for people across the company but 250 of those are resolved in Canada through another system run by one person. They still need to be assigned and tracked through Snow but can those 250 be closed by that person easily?
Baseline functionality does not allow for bulk case closing of cases. A workflow for the particular HR Service could be created and used to direct the workflow and close the cases.
Yesterday, someone asked if you could create Bulk HR Cases that were already in a Closed State. Apparently, you can!!!! Check out this Community post for more info: Create Bulk "Closed" Cases.
Q- For assignment groups for security, yesterday we learned that we can create a Child/Parent relation with other group, which means that you can create a multi level hierarchy as you create the child/parent relations, is there a particular reco for best practice on the number of levels of child/parent that you should allow in this hierarchy?
Good point, Lena. Setting the state in the HR Template is a viable option, but I do want to point out that this could have repercussions. I work with a client that was having issues with the Awaiting Acceptance workflow; it wasn't being triggered on certain cases. I discovered that their HR Professionals were creating cases in the Closed Complete state, and when that happens, the Awaiting Acceptance workflow is not triggered. I believe this use case of setting the state to Closed Complete using the HR Template would also not trigger the Awaiting Acceptance workflow. An argument could be made that if we're creating bulk cases, we probably would want to skip the Awaiting Acceptance phase anyway, which is fine. But something to think about.
Another translation question, regarding HR Services. When building new services, do companies find better success using translated text for the new service or is it easier to manage if you just build a french version of the service that is it's own thing.
Scenario: I created a new HR Service and checked the "Show case to subject person" box. A month later I edit the service and un-check the "Show case to subject person" box.
Q: Will cases created before the "Show case to subject person" was un-checked be viewable by the subject person?
I wouldn't necessarily say there is a best practice for number of levels of child/parent in group hierarchy. I have worked with clients that have 4-5 level deep hierarchy, but I would say that is not common. More commonly, I have worked with clients that do 1-2 level deep hierarchy. Ultimately, you need to do what fits the organization and work to keep it manageable.
Can we configure the Subject for field for multiple user ID's
use case, we receive a call from a manager who has multiple employee that need assistance with a question. We want to capture the full scope of the population.
Note: our IT current use multiple users embedded with our security request forms
There is no limit to how deep the parent/child relationship can go. It's really more a matter of what works for your organization. One thing to note is that a System Admin will need to update the default search used for the Manage HR Groups module. In the base instance, it is only looking for groups that have "HR" as the Parent or the HR group itself.
That said, I would recommend you try to limit the hierarchy to only go 3 or 4 deep just because it could easily get confusing to administer. For example HR -> HR Payroll -> HR Payroll EMEA -> HR Payroll EMEA GL Specialists. You'd need to ask yourself, "is it adding value to add an additional layer/group or could this be accomplished with Skills?"
It is going to depend on what the default language of the system is and whether users have the ability to select their language or not. If the default language is English, then the initial HR Service will be connected to the English language. If the users are able to change their language to French, the initial HR Service will be displayed unless translated text is built out for the French language.
So what this means is you could create the initial HR Service in French, but it will be associated with the default language of the system. If the default language is English, users will see your French version when English is selected. Maybe that's not a big deal in this case? If a translated version isn't built out in the actual French translated text, the initial version will be displayed.
I tested this out, and the answer is yes, that if you create the HR Service with the checkbox unchecked, and then a month later, go into the HR Service and check the checkbox, it is retroactive and those previously created cases are visible to the Subject Person now.
That helps. I think I'm just trying to cut corners. But I think eventually we would need to use Criteria to have the Portal display cases dependent on language too.
Only users with the HR Basic role can be added as a Collaborator. I like to think of a Collaborator as an HR Professional that wants to stay "in the know" on a case (such as a case that was transferred and the original assignee still wants to follow along with the new case) or someone that is going to assist with the resolution of the case. This is the information provided on the Product Documentation site:
Add collaborators or other HR agents to the case.
Only HR agents can be added as collaborators. For example, an HR agent can add them self as a collaborator after transferring a case to a different agent or group. This action permits the original agent to still track the case. Or, an HR agent can add another HR agent as a collaborator to request help. Adding a collaborator populates the case on the collaborations list.
Other factors related to adding collaborators:
Collaborators can remove themselves from the case as long as the user is not the Assigned to person. To remove yourself, highlight your name in the Collaborators list and click the X.
Collaborators are not required to be part of the assignment group.
Assigned to person can add or remove collaborators.
Collaborators cannot add or remove collaborators.
Notifications are sent to collaborators when added to the HR case.
Note: Adding collaborators can alleviate the amount of emails requesting help on an HR case by consolidating communication.
Watchlist:
Any user in the system can be added to the Watchlist. Adding someone to the watchlist is going to allow that user to receive certain updates or notifications regarding the case. This is the information provided on the Product Documentation site:
The list of users who receive notifications regarding this case.
Anyone in the company can be added to the Watch list. For example, an employee requests a travel visa. Add the manager of the employee to ensure that updates are communicated.
Click the Edit Watch List icon to add users. Click the Add me icon to include yourself.
Baseline functionality does not allow for multiple user IDs in the Subject Person field. It could be configured, but I would highly discourage customizing this functionality. My recommendation would be to create a case for one Subject Person (maybe the manager?) and then create child cases for the other users (the employees), using each one as a Subject Person for each child case.
Employee Service Center - Creating Content for an audience. beyond creating the audience and attaching to the content. How do we add employees outside of the typically criteria?
use case: We want to built a Manager subpage where managers can access HR, IT, facilities, etc content from a manager perspective. We create the audience based on the system criteria for manager but we also want to be able to provide access to ad hoc leaders or other employees for various reasons. Do we have to create an ad hoc audience and manually manage that list or is there another pre built ability to do this like in the KB?
You have multiple Audiences tied to a piece of portal content. So you could create an audience for Managers and an audience for "other employees" and add both audiences to the content. Users only have to meet one of those audiences to be able to view the content. If you decide you don't want the "other employees" to be able to view the content, you remove them from the Audience selection, and they are no longer able to view the content while the Manager view remains intact.
If the intranet home page is HR specific, typically yes, the ESC is used to replace an existing HR intranet home page. I have worked with other clients that have a more generalized intranet home page, and what we have done is once the ESC is live and running, the organization removes the HR-specific info from the intranet home page, so there's no duplication of content, and then they add a link on the intranet home page to the ESC, so employees can access the HR related info.
Repeating this since Localization has come up multiple times in class. There is an eLearning in our Learning Portal for Localization, but it's more of an intro to Localization. Here's a link: Localization eLearning.
Also, there are a couple of Localization Workshops at K19 CreatorCon! Perfect timing, huh? Search your agenda for "localization." I got a sneak peek at the lab guide for CCW0689 and it was fantastic! Definitely not intro stuff.
Regarding Can Read, Can Contribute, Cannot Read, and Cannot Contribute fields on a Knowledge base vs a Knowledge article. Let me give you a personal experience:
I was asked to update a Knowledge article, but I did not have Edit access to the article. The article author added me as a collaborator, but I still did not have Edit access to the article. We later found that there was a Can Contribute User Criteria set on the Knowledge Base level. I did not meet the User Criteria, so I was prevented from editing any article in that KB, even though I was listed as a collaborator.
So, when the User Criteria is set at the KB level, it impacts every article in that KB.
I apologize for the delay! I did not receive a notification for this. I just happened to be going through comments to make sure I hadn't missed anything, and it turns out I did!
Baseline functionality does not allow for State to be updated from the List Editor. I did add the list_updater to my HR Admin in my student instance, and I am not seeing the options that should be available with that role.
your student instances have a lot of demo data that has been preloaded and all plugins have already been activated. That is not the case with a Developer instance. You'll need to activate them yourselves.
Remember that in the HR Fundamentals class, you were logged in as the HR Admin. If you want to experience your developer instance as the HR Admin, you'll need to log in as Admin and assign a password to the HR Admin. Then, you will be able to log in as the HR Admin. Group membership for the HR Admin will need to be set up, too
If you choose to do your work as the system Admin, you will need to switch application scope sometimes. You can turn on the application scope picker under the Global Settings > Developer & toggle on "Show application picker in header."
Here is a document I share in my HR Fundamentals classes for those students that are interested in activating plugins in their own Personal Developer Instance.
I have received a couple of questions about the contextual search feature on the HR Case form. If you create a new Knowledge Base, it does not automatically pull the articles from that new Knowledge Base into the Knowledge Search Results on the HR Case from. To do it, you need to engage a Sys Admin or have Sys Admin rights. This is not something that baseline functionality allows HR Admin to do.
First thing you need to do is obtain the sys_id of the new Knowledge Base and copy/paste it somewhere that it will be readily available.
Next, navigate to Contextual Search > Search Contexts. Open HR Knowledge Base Search. On the Resource Configurations Related List, click knowledge. On the Search Resource Context Properties Related List, click Condition. When the condition opens, you want to add the appropriate Knowledge Base sys_id to the Value field. Once that is updated, you will now be able to search for articles from the new Knowledge Base on the HR Case form.
Another question I have received is how to configure contextual search on a record producer. Here is the link to the information on the product documentation site Define contextual search for record producers
There are a few additional steps not mentioned at the end of the article. After the record producer configuration is defined, it creates a contextualsearch variable on the record producer; however, that doesn't automatically make contextualsearch available on the record producer on the Employee Service Center. You need to go into the contextualsearch results variable and define the Widget under Type Specifications as ContextualSearch - Inline Results.
I could not have asked for a better class and staff. I'm going to take the opportunity for some restoration and then read through the myriad comments here and take it all in. Thank you all so much for getting Knowledge off to an amazing start!
