Leveraging HR Security in S3 with Landmark GHR Implementation

Sort:
You are not authorized to post a reply.
Author
Messages
Demi
Veteran Member
Posts: 67
Veteran Member

    I am curious as to how other organizations handled, or plan to handle, user security on the S3 side when implementing various systems over to landmark. We’re an on premise site and have a full set of Roles and security rules defined in S3. Now we are implementing GHR; moving our HR and PA systems over into Landmark under GHR.  I’ve been told that our plan is to build GHR on landmark as our ‘system of record’ and then use BOD’s to populate data back into S3. Our users will still be able to access the HR and PA forms on the S3 side but once GHR is implemented, as Inquiry ONLY. This will require a lot of changes or new development within our lawson security and I am trying to determine my best course of action to accomplish this. Thoughts and suggestions are all welcome.

    Roy
    Basic Member
    Posts: 8
    Basic Member

      This is a loaded question.  We are also on-premise.  I'm on the IT side of things, but responsible for S3 and GHR security, so I might be able to shed some light on it.

      Yes, GHR will be the "system of record".  You will set up delivered interface settings for "HRM Interface" in GHR that you will tell what information to cross over to S3.  Depending on your set-up/requirements, various flows will trigger each time you make changes to employees, work assignments, etc, which populate data in "interface tables" in S3 (LT11 forms), then you will run "LT111" or "LT101" to "commit" those changes to S3.  In our case the HRIS team takes care of running the LT111 interface.

      As for security, GHR comes delivered with sets of security roles.  Also, in our case, in S3 we have mostly one single role that defines what the user has (with exception of the self-service roles), so the transition to GHR may have been easier, but essentially you will have to review the delivered GHR security roles to see if the pre-defined roles fit.  In our case, HR had certain requirements from S3 that we had to maintain in GHR as well, which means most of our security would be custom, based on the delivered GHR security roles.  It takes someone familiar with GHR and LPL and security to define and maintain GHR security.  I came into the GHR world relatively green, but we hired an infor consultant to help us map out and define our GHR security.  It has changed a lot since we implemented GHR in 2017, you will periodically have to review and update any custom security you have defined, in particular if you want to stay up to date with the CUs for GHR and Landmark that are released every 2 months or so.

      For go-live, in S3, I replaced most of our "update" security classes for HR with "Read-only" versions for most of the S3 security roles, with exception of the roles for a couple of key corporate HR folks (HRIS in particular).  HRIS also needed access to the LTxx and LTxxx forms for the interface processing.  To my knowledge most of the HR staff at our facilities rarely access S3 HR for anything because they use GHR for their day-to-day functions, unless they need to work with Payroll which is still in S3.

      Hope this helps

      You are not authorized to post a reply.