Use Custom MDF, People Profile (PP3) and workflow to build a system tracked Sarbanes-Oxley (SOX) compensation plan approval
During the last year, three different clients of mine asked if there was any out of the box functionality to provide a system generated, tracked and stored record for Sarbanes-Oxley (SOX) approval of the annual corporate compensation plan. Of course each of these requests had specific customer nuances of what exactly needed to be viewed and approved, so there was no single delivered feature to accomplish this task.
While there was no box you can just check and have it all done, there are indeed options to satisfying what your customer wants, you just have to use the configuration tools SuccessFactors provides to administrators to extend a little further than the basic functionality. Since enough people had asked me about it, I thought it might be worth documenting how it can be done.
What follows is a brief step-by-step configuration guide for how to build a SOX approval mechanism into your SuccessFactors compensation process. I’ll note this again during the instructions but there are lots of little modifications you can make to what I’ve done below to suit your needs. My way is not the only way, but I have found it to be successful in meeting my customer’s needs. All of what you’re about to see is configurable in admin center with the exception of the YouCalc dashboards I’ve built that I can explain in more detail in another post. With that little safe harbor statement out of the way, let’s get building!
The core of this is going to be a custom MDF object that’s available on the People Profile (PP3). When it comes to custom MDF objects, you can only get them to be available on PP3 when there’s just one of that object per person and the userid is the external code value. We also know we can expect over the years that an approver will have more that one approval to provide. In my case it’s also possible that more than one unique compensation process may need to be approved by the same person in the same year. For those reasons we need to create a parent/child object relationship between a parent and child object. We’ll do all of this in “Configure Object Definitions”.
First the parent, which will allow us to be usable on PP3. It’s a pretty straightforward configuration where the external code is changed to be data type = user and the label for it is changed to “Approver”. You can see below I’ve already built and assigned the workflow but later we’ll get to where I set that up. I also marked the externalName to be not visible and not required.
Next we need to build the child object. I won’t write out all of the details here, but below you can see the basic configuration. The important parts are the cust_* fields. These are you can place whatever fields you think are important to associate with the approval and are what you want your approver to see. In my case I include the comp process, the approval request date, and most importantly the attachment so the approver has something to review.
Now that we have the parent and child objects, we’ve got to associate them. We’ll do that back on the parent object as shown here. Easy breezy!
The next step here is to create a screen for these objects so our end users (i.e. approvers/requestors) have something to interact with on the front end. To do that we go to the “Manage Configuration UI” in admin center and build our own screen. Click “Create New”, give it an ID and then find our SOX approval parent object.
The bottom half of the page now looks like this
Because I don’t want to see that effective date on the screen and it’s not a required field, I went ahead and hit the delete button. You should hit it too. Feels good, right?
The stuff on the bottom is all stuff I want my approver to see so I’m keeping it all. If you see any changes you want to make, my preference is to change as many of them in Configure Object Definitions as possible. I could have hidden the effectiveStartDate there as well, but I did it here just to show the possibilities.
So once we save this, we need to get it to show on PP3. Let’s go over to “Configure People Profile” and create a new view. Scroll all the way to the bottom and click “Add a new section”.
This will create a new Untitled section, which we’ll modify to be whatever suits your need. Once you have that labeled, click save in the faaaaar lower right.
If you’re using Chrome for this, the next part is like a carnival game where it’s unfathomably difficult to do. You have to grab the Live Profile MDF Information box from the right and drag it into an open block from your newly created view. Whomever invented this erratic drag and drop functionality definitely enjoys tormenting people.
Once you finally get your Live Profile MDF Information box on your view, now you have to select the screen you created earlier and again hit save.
We have to permission this portlet now for people like the compensation administrators to see for the population they have access to. You can obviously do whatever RBP configuration is best, but it’s important to note that the way I’ve set it up makes it so you don’t have to give the approver access to the portlet. I didn’t configure any special permissions on the object, so all we need to do is grant the PP3 view.
The next task is the workflow. I’ve said it several times now, but you can configure this to suit your needs. If you want to include a Compensation VP before your final approver, then go crazy. In my case, I just have a single approver. To do this we need to go to the old school Foundation Object configuration spot, “Manage Organization, Pay and Job Structures”. Within there, choose “Create New” and choose “Workflow” from the list. Below is my single approver “self” configuration. This means that when I create an object on my approval’s portlet, they will be the approver of the object.
Once you save this, you have to go back to the original parent object from my first screenshot and assign the object to the workflow. That's it! Now it’s time to put it into action. I created an attachment field in my object and we need to actually attach whatever your SOX approver is going to officially sign off on. I will cover this in another blog, but in my case I’ve actually built some pretty cool YouCalc dashboards that pull data out of my compensation worksheets and summarize it in ways that exactly match customer requirements. YouCalc is a bit of an acquired taste and customers can’t create custom dashboards for themselves however as shown below and on some other blogs by super cool people, they have almost limitless capability for what a customer might want to report on.
Now that you've got your results to be attached (in my case I just exported an above list), now let’s go to our user’s PP3 and choose our SOX Approval view
Click the pencil icon and see how our objects come up. Go ahead and fill out the main date and then click the add button to create the SOX Approval Details. Below you can see I’ve entered some basic details and attached my file.
Once I click save, look what happens. Our workflow gets triggered!
The workflow will use all of the normal SuccessFactors workflow capabilities and it will trigger an email to Audrey letting her know a workflow awaits her once we click “Confirm”. For her to actually act on the workflow then, she just needs to login and the item is waiting for her within her To-Do section.
She can approve it right from here, but if she chooses to click on the link or the button, she’ll be taken into more detail. Within that detail you’ll again see we’re just looking at standard SuccessFactors behavior that matches our workflow configuration where she’s able to comment, reject or approve the request. All history of activity is tracked on the right hand side. Most critically, Audrey is able to see my SOX results attachment I downloaded from my YouCalc dashboard and can then make her informed approval of the plan results.
Once she approves this, the requestor will get an email saying the workflow is complete and because I said to not show pending data on my object configuration, the approved SOX results will be available on the portlet.
And you can use the workflow log if you ever need to produce proof of the transaction in “Manage Workflow Requests” and you can see the status, or if you click into the request, all of the details we saw earlier.
I know I’ve said this a hundred times by now, but I again want to clarify that this is not the only way to accomplish this task. There are lots of little nuances you could have modified to make these objects, portlet, workflow, etc work specific to your needs. My way isn’t the only way, but it definitely works and is a great illustration of how you can easily extend the delivered capabilities of SuccessFactors using the tools they provide to customers without some egregious six month customization window while still providing a solid deliverable.
If you need assistance with your SuccessFactors implementation and think I might be able to help you, let me know.
Opmerkingen