Where is the problem? Is it a bug?


I've been involved with a lot of implementations and upgrades over the years and I'm certain that every one of them had hit a snag at one point or another. Whether miscommunication, improper training, or technical issues, all of these needed one step to get to the solution - an evaluation of where the problem lived.

Not just what issue are we dealing with, but where is the actual problem?

Is it a bug?

One project I was involved with had major allocation issues in the storeroom. Items were being allocated to orders before the item was even in stock. This appeared to be a major bug that would require escalation to the vendor before the client could go live, and that was the path the project manager was taking to get to a resolution.

I was one of several supply chain consultants, primarily brought in to help with pre-go live training and go live support. In other words, I was just there to help the team cross the finish line.

I don't recall if I was asked or if I just overheard about 'the bug' that was causing frustration, but I decided to look at the system settings.

The flag that allowed allocation on open PO's was set to 'No' correctly, yet the system was allowing it. That made no sense, so I kept digging and eventually found another setting that seemed to be contrary to the no allocation setting.

I don't remember the actual setting now, but I do remember that it seemed to allow for allocations when an item was on order (not yet received) and so I brought my discovery to the project leaders.

Expecting a high five for my doggedness, I was surprised when I was told that my discovery could not be the cause of the issue since the other allocation flag was set to no.

To their credit, however, they did allow me to run through some system tests and I found that this one setting, against all logic, was in fact where the problem lived.

Issue solved, go live saved, bonus awarded (not really). By this point everyone was just ready to get the issue behind them and focus on the important go live.

Not just answers, providing solutions

Infor Federation Services - Lessons Learned, Mistakes Made


When the company I was with first implemented IFS we made a lot of mistakes, quite frankly because no one told us the right way to do it. We followed steps that seemed to make sense from past processes in the Infor Lawson world, but which didn't work well in this IFS, ION, & BOD world we were moving to.

Security Roles - we created all of the security roles (from Lawson, Landmark, GHR & EAM) in IFS instead of feeding them from these systems via the Security Role Master BODs. This created problems when we later tried to utilize some features of 'role control' from GHR.

You can default roles on job/positions in GHR and we were hoping to automate removing roles when someone changed their job/position. The problem was that the roles in IFS were tied to multiple Logical IDs and simply removing them in GHR (and feeding those updates to IFS) didn't work.

When we removed the role from the user in GHR and sent the process security user master BOD to IFS, IFS didn't remove the role from that user (because it was associated to multiple Logical IDs) and the sync security user master BOD back to GHR added the role again.

Mistake made, lesson learned. Only associate one Logical ID to a Role by using the Sync Security Role Master BOD to add them into IFS with the Logical ID of the sending system.

Another issue we encountered in role maintenance - because we didn't understand our new world - was not cleaning up roles in Lawson that had been added only for the sake of using ISS sync with Landmark.

The old process required all Lawson security roles to be built in Landmark and all Landmark roles to be built in Lawson in order to keep the users in sync via ISS. This is not a requirement when security if maintained by IFS.

This duplication just clutters up IFS by associating both Logical IDs to these roles, especially since most users don't need access to non-GHR/FSM Landmark. [Yes, Virginia, there are two different Landmarks.]

Mistake made, lesson learned. Before migrating to IFS, take a look at your current setup and take the time to clean up what's no longer going to be required.

Not just answers, providing solutions

Infor Federation Services - Logical ID for your Infor applications



Roles are associated to Logical IDs and Logical IDs are associated to the various Infor (and non-Infor) applications that you can access within Ming.le.

Within the Admin Settings menu, select the application to view and look for the Logical ID tied to that system.

Not just answers, providing solutions

Infor Federation Services - Are you a User?



We previously discussed Role Management but this time we're interested in User Management. Users are updated in the system(s) by the Security User Master (SUM) BOD but where do you maintain those users and their roles?

Within Ming.le you would access the User Management menu (click the Person icon in the upper right of your screen for the available menus).

Search for the User you wish to maintain and click the User Details link to open that user



Within the User, you can assign the Roles you want this user to have for the various Infor systems.


Click the + icon to add a new Role to the current user



The Logical ID identifies what system(s) are associated to each Role. In an ideal world, each role would be linked to one Logical ID, but you can tie more than one role to a system (see Role Management).

Check the box for the Role(s) you wish to add and click Add & Close (or Add if you need to add more roles on a different page). Once you've saved the User updates the SUM BOD will be triggered. This BOD will update the User's Roles in each system required.


Once the User receives access to a system, that system's icon will be available to them in the App Switcher menu.

Not just answers, providing solutions

Infor Federation Services - What Role will you play?


While security roles are stored in IFS, they are actually 'owned' by the systems they sync from.

Whether Landmark multi-tenant (MT), Landmark single tenant (ST), Lawson, EAM, Mongoose, etc. these systems own the roles and they send a Sync.SecurityRoleMaster BOD to IFS to create them.

You can create these roles in IFS, but that only confuses things when you later want to manage the roles assigned to users.

Here's a for instance; you used to have to create the same security roles in both Lawson and Landmark and keep the users in sync via ISS - this isn't true once you move to IFS.

Under this process, if a user needs a Lawson role assigned to him or her that role first needs to be synced over to IFS (from Lawson) and then assigned to the user in IFS. IFS will then send a Sync.SecurityUserMaster (SUM) BOD over to Lawson with the roles attached to the user.

In fact, the SUM BOD contains all of the roles per user for every system you're syncing to via IFS (by Logical ID). Those roles are rebuilt (removing the old roles and adding the new ones) when the SUM BOD is processed.

You can, if you decide to, update the roles for a user in Lawson and it will in turn send a Process.SecurityUserMaster BOD request to IFS asking it to remove the role from the user. Once IFS consumes the Process BOD request, it will re-send the Sync SUM BOD back out to make the change 'official' (for lack of a better term).

If a Role in IFS is assigned to more than one Logical ID (LID) - say Lawson and Landmark ST - and you remove the Role in Lawson then IFS will see the Role assigned to both Lawson and Landmark ST and it won't remove it from the user (it sees it as a valid Landmark ST role assignment).

In this case, the Sync SUM BOD will actually add the Role to back to the user in Lawson. IFS couldn't remove the role from the user because it was associated to two (or more) Logical IDs and so the security update back to Lawson will show that role as being valid to the user.

If you only setup the assignment of one Logical ID per Role (by letting the system which owns the role sync it to IFS),  you can perform the role updates in either that system or IFS.

Best practice, however, is to maintain which Roles are assigned to Users in IFS.

Not just answers, providing solutions

Infor Process Designer - GLTRANS ObjID References


We had an interesting problem to solve which involved pulling data from the Lawson S3 GLTRANS table (based upon ObjID values). We wanted to pull 2000 records at a time and then trigger another instance of the flow to pull the next 2000, and so on, until all current records were captured.

We didn't want to work with two different versions of the flow, one with the beginning range value preset and one with it being passed from the Trigger. That meant we needed a variable assignment that would know when the variable existed and when it didn't.

So, on the Start node, when we defined the beginRange variable we used a particular function to create the variable when it didn't exist but to utilize it when it did.

beginRange = (typeof beginRange==='undefined'?0:beginRange)

In some programming languages, this is referred to as an 'immediate if' statement, meaning to validate it now. We couldn't simply tell IPA to set beginRange=beginRange because the system returned an error saying that beginRange is undefined (when it didn't already exist as a Trigger variable).

To solve this, we found a function typeof which would evaluate the variable, even if it was undefined. In fact, that is the answer we wanted in the immediate if. If beginRange was undefined then assign the zero value to it, but if it wasn't undefined then assign it to it's own value.


The next problem to solve was to capture the first and last Obj ID values from the query loop. Notice in the JavaScript expression above, we included the record number reference when we assigned the query's Obj ID value to the firstObjId variable.

firstObjId=LwsnQuery3220_0_OBJ_ID

You may remember that the first record value in JavaScript is zero, not one. So we simply included the record number reference in the value we were looking for. You may have also noticed that we did not include a record number reference for the last Obj ID value.

The last returned value in the query (which was set to &MAX=2000) will always the value we're looking for so we didn't need to reference the record number. This also has the advantage of not having to account for when the query returned less than 2000 records.

Having captured the first and last Obj ID values, we could use them later within the flow and for when we triggered the next instance of the flow. The lastObjId value from the current flow became the beginRange variable value used when the next instance of the flow was triggered.

Not just answers, providing solutions