I’m trying to build a GI that ties a Business Event to the Username who triggered the Action that drove the business event. In some cases we use a ‘kiosk’ style machine to allow people to clock in, and knowing which machine they clocked in on will help us determine who should review their time clock entries. I have the BPEventHistory table pulled, but I can’t figure out how to show the username of the person who executed the action that triggered the BE.
Answer
Table Showing who ran an Action
+1Best answer by lairdtim
I see, so you’re getting the username into the GI from which they’re running the business event so that then you can drop it in a field / attribute (via import scenario) when they execute the action?
I don’t have an answer to your exact question, but I did something very similar today and you may be able to plagiarize portions of it.
Our need was a custom approval process for AP Bills (long story, but we can’t use the built in approval flow). I have a business event that handles this, tied to a GI that lists all of the bills that are available for approval. I wasn’t able to capture the user that actually did the approval, though.
What I did was find a way to join the Users table back to APInvoices. The join is based around finding a field in the first table that will never equal the value in the other table (I used apinvoice.refnbr does not equal users.email).
This duplicates each APInvoice result for every user in the system. But, I added a condition for Users.PKID = @Me on the GI, so that I only got one result per core record, and by adding the username as a value in the GI, it is then available to the import scenario that the business event runs.
If there’s a cleaner way, I’m all ears, but this gave me the current user in the results of the GI, and I now can store that on a UDF on the APInvoice record.
Yes, by getting the username into the GI results, I am able to plug it into a UDF on the APInvoice record. In your case, you could capture the username (terminal) that the employee is clocking in on.
I don’t have an answer to your exact question, but I did something very similar today and you may be able to plagiarize portions of it.
Our need was a custom approval process for AP Bills (long story, but we can’t use the built in approval flow). I have a business event that handles this, tied to a GI that lists all of the bills that are available for approval. I wasn’t able to capture the user that actually did the approval, though.
What I did was find a way to join the Users table back to APInvoices. The join is based around finding a field in the first table that will never equal the value in the other table (I used apinvoice.refnbr does not equal users.email).
This duplicates each APInvoice result for every user in the system. But, I added a condition for Users.PKID = @Me on the GI, so that I only got one result per core record, and by adding the username as a value in the GI, it is then available to the import scenario that the business event runs.
If there’s a cleaner way, I’m all ears, but this gave me the current user in the results of the GI, and I now can store that on a UDF on the APInvoice record.
+1I see, so you’re getting the username into the GI from which they’re running the business event so that then you can drop it in a field / attribute (via import scenario) when they execute the action?
I don’t have an answer to your exact question, but I did something very similar today and you may be able to plagiarize portions of it.
Our need was a custom approval process for AP Bills (long story, but we can’t use the built in approval flow). I have a business event that handles this, tied to a GI that lists all of the bills that are available for approval. I wasn’t able to capture the user that actually did the approval, though.
What I did was find a way to join the Users table back to APInvoices. The join is based around finding a field in the first table that will never equal the value in the other table (I used apinvoice.refnbr does not equal users.email).
This duplicates each APInvoice result for every user in the system. But, I added a condition for Users.PKID = @Me on the GI, so that I only got one result per core record, and by adding the username as a value in the GI, it is then available to the import scenario that the business event runs.
If there’s a cleaner way, I’m all ears, but this gave me the current user in the results of the GI, and I now can store that on a UDF on the APInvoice record.
I see, so you’re getting the username into the GI from which they’re running the business event so that then you can drop it in a field / attribute (via import scenario) when they execute the action?
I don’t have an answer to your exact question, but I did something very similar today and you may be able to plagiarize portions of it.
Our need was a custom approval process for AP Bills (long story, but we can’t use the built in approval flow). I have a business event that handles this, tied to a GI that lists all of the bills that are available for approval. I wasn’t able to capture the user that actually did the approval, though.
What I did was find a way to join the Users table back to APInvoices. The join is based around finding a field in the first table that will never equal the value in the other table (I used apinvoice.refnbr does not equal users.email).
This duplicates each APInvoice result for every user in the system. But, I added a condition for Users.PKID = @Me on the GI, so that I only got one result per core record, and by adding the username as a value in the GI, it is then available to the import scenario that the business event runs.
If there’s a cleaner way, I’m all ears, but this gave me the current user in the results of the GI, and I now can store that on a UDF on the APInvoice record.
Yes, by getting the username into the GI results, I am able to plug it into a UDF on the APInvoice record. In your case, you could capture the username (terminal) that the employee is clocking in on.
+1
This worked great; I basically did copy the logic exactly and it’s functioning as expected. GREAT IDEA!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.