If you are getting errors when provisioning users, these errors cannot be auto-corrected.
In SSOCONFIG, use the Data Check for Actor data which identifies errors that exist so you can fix them manually.
From the LSF server, run the ssoconfig utility.
ssoconfig -c- enter the ssoconfig utility password when prompted.
- select Manage Federation.
- select Perform Pre-Sync Data Check.
- Select Check Actor Data
- Review the output for errors. For an Actor record with missing or invalid email address, you will have to correct the errors manually.
- When you have finished correcting Actor errors, rerun the Pre-Sync Data Check to verify that all errors have been corrected.
Results of the Pre-Sync Data Check are written to the security log file LAWDIR/system/security_provisioning.log
If you run into this error, it likely means that many of your batch jobs in Lawson are going into recovery. The reason this may have occurred is due to a domain name change or possibly an accidental password reset.
To resolve, first login into LSA, then go to Manage Privileged Identities.
Once there, click the Environment named service ie. LSFPROD, LSFTEST or however yours is named. Select the BATCH key and find out what user is assigned under it.
This BATCH key may be named differently so check your lajs.cfg file under RUNUSERKEY as shown below in the system folder.
If you know the latest password login to LID with it first to confirm.
After confirming, type the password in the password field shown below and remember to click CHANGE after you confirm the password:
If you’re able to track down the right user and update the password, your jobs should recover without too much trouble. If errors like this keep popping up or if you would rather not spend time digging through configs and logs, our managed services team can step in. With a dedicated group of Lawson experts behind you, we handle issues like batch job failures, user access, and system troubleshooting so your team doesn’t have to. Our goal is to keep your Lawson environment stable and reliable while you focus on running the business.
This article will give you all the information you need to know about the Infor Year End Regulatory Patching that will be released by the end of the year.
Why Year-End Updates Matter
As you probably know the YE regulatory patches
- Will keep you in compliance with your w2s,1099 and/or ACA reporting.
- They will Ensure the Lawson data is accurate for tax filings and vendor payments
- Many forms or report errors are symptoms of missing patches
- Being Current on Updates will maintain your Lawson functionality and supportability
TimeLine
Infor will release a KB article at the end of November. That article contains the dates, and the documentation that is needed for patching. Make sure to subscribe/follow the article so that anytime they make a change to it, you’ll get notified.
The YE communication process starts in Nov and then the downloads will be available around the beginning of December. That is when the install files, the PDF and the change documentation will be available.
Products and Documentation
To get the documentation and downloads, log into InforXtreme and go to product downloads.
You should see a link to product search on the right-hand side.
Download Search
In the Product Search box, enter the year,2025, and Year-End. That search will return many links for all platforms. Look for the one that fits your organization
You only need to download what products you actually use so if you don’t run benefits out of Lawson, then you will not need to download the benefit Patch.
Reviewing The Changes
For the changes, once you get your tar file, untar them and then inside there’s will be two HTML documents one of them is a Delta read me and the other one is a regular read me file.
The Delta lists the major changes. It’s a one-page high-level view of what changes are in this patch. The regular read me file is more detailed. Review both of those and look for any job parameter changes on any forms or in a batch jobs, if there are any, it will require you to create a new batch job because the new parameters on the batch job will cause the fields to shift or move, so the old jobs parameters could be off once the patch is installed. The documentation will tell you if the jobs must be recreated because of perimeter changes.
other changes that may occur with YE patches
- they may add fields to a form. This would impact your add-in queries and uploads.
- they might change the interface file by adding a column to an interface conversion file (ex AP520)
- Be sure to search for any database changes in the readme file by Searching for the key word dbreorg. If a DBreorg is required, it means that the structure of the database will change.
- If there are new forms with the patch, you will need to apply security rules to the new forms for the users who will need to have access to them.
Form Changes
You want to review:
- If AP145 has changes- make sure all your boxes are set up correctly
- The AP245 may have the most changes in the form. They may add new tabs and/or remove tabs. They may add/remove fields, they may move fields from one tab to another. If that is the case, it is best to add a new job with a new name for the AP245.
Installation
- The installation process is the same as any other CTPs.
- You download the patches into a folder/directory on the lawson server application server
- Use the lawappinstall command to preview, update on each patch and run activate after all patches have been run with update. The activate will pick up any patches that ran in update and haven’t been activated.
- Perl GENDIR/bin/lawappinstall preview PDL
- Perl GENDIR/bin/lawappinstall update PDL
- Perl GENDIR/bin/lawappinstall activate PDL
TESTING
Test in a non-production environment first before you apply the patches to production. Test several different types of processing just to make sure that nothing has been impacted by the changes.
- Run daily processing; inquiry on forms
- run a couple of daily batch job
- process payroll and make sure that the taxes are calculated correctly
- validate the data; verify the benefits are deducted correctly
- run your month end process
- run 1099 and validate the data
- run W-2s
- run ACA (Affordable Care Act)
Recommended Timeline (Nov–Jan)
- November – Install patches in non-prod and begin testing
- December – Validate reports and reconcile data
- January – Finalize and submit W-2s/1099s
Key Takeaways
- Test early and document everything.
- Communicate timelines with HR, Payroll, and Finance teams.
- Leverage Nogalis resources for troubleshooting and guidance.
When working with Amazon Athena, SQL syntax quirks can sometimes trip up even seasoned database professionals. In this post, we’ll look at several syntax patterns that come up often when building queries in Athena.
Common Table Expressions (CTEs) with WITH
Athena supports CTEs, which allow you to define temporary result sets that can be referenced later in the query.
✅ Correct usage:
WITH cte1 AS (
SELECT column1, column2 FROM some_table
),
cte2 AS (
SELECT * FROM cte1 WHERE column1 > 100
)
SELECT * FROM cte2;
❌ Incorrect usage:
WITH cte1 AS (SELECT * FROM table1)
WITH cte2 AS (SELECT * FROM table2)
SELECT * FROM cte1 JOIN cte2 ON …;
Athena requires all CTEs to be defined under a single WITH keyword, separated by commas.
Window Functions: LAG() and ROW_NUMBER()
When you need to look at values in previous rows or assign sequence numbers, Athena provides window functions:
- ROW_NUMBER()
Assigns a unique number to each row within a partition. - ROW_NUMBER() OVER (
- PARTITION BY employee_id
- ORDER BY start_date ASC
- ) AS row_num
- LAG()
Retrieves the value from the previous row in a partition. - LAG(salary) OVER (
- PARTITION BY employee_id
- ORDER BY start_date ASC
- ) AS prev_salary
These functions are especially powerful when tracking changes over time or comparing current and prior values.
BETWEEN is Inclusive
In Athena, the BETWEEN keyword includes both the lower and upper bounds of the range.
WHERE event_date BETWEEN DATE ‘2021-12-01’ AND DATE ‘2021-12-31’
The query above returns rows from December 1 through December 31.
If you want to exclude the upper bound, you’ll need to switch to an explicit condition:
WHERE event_date >= DATE ‘2021-12-01’
AND event_date < DATE ‘2022-01-01’
No APPLY, Use LATERAL Instead
If you come from SQL Server, you may be familiar with CROSS APPLY or OUTER APPLY. Athena does not support APPLY. Instead, you can achieve similar functionality with a LATERAL join.
SELECT e.*, x.*
FROM employees e
CROSS JOIN LATERAL (
SELECT *
FROM salaries s
WHERE s.emp_id = e.emp_id
ORDER BY s.effective_date DESC
LIMIT 1
) x
Here, LATERAL allows the subquery to reference columns from the outer query, just like APPLY would in T-SQL.
Key Takeaways
- Use one WITH clause with multiple comma-separated CTEs.
- Use window functions like LAG() and ROW_NUMBER() to track changes or assign row order.
- Remember that BETWEEN is inclusive in Athena.
- Replace APPLY with LATERAL joins when you need correlated subqueries.
By mastering these syntax patterns, you’ll avoid some of the most common pitfalls when writing Athena queries, and make your SQL more efficient, readable, and powerful.
After updating the memory on the application server the flexform application started having issues with printing. The Memory increase was reverted and decreased it to what it was(16g).
At that point, admin was not able to get the Lawson service to run. The lawson.insight Environment “lawprod” service on Local Computer started and then stopped. Some services stop automatically if they are not in use by other services or programs.
Resolved by rebooting all three servers (DB, LMK, APP).
To add memory to the application server and not impact Flexform, you must work in tandem with Flexform so that they can get a new license implementation based on the new memory added.
When working with Amazon Athena, a common stumbling block is using LIMIT inside a subquery. Unlike many other SQL engines, Athena does not support LIMIT in scalar subqueries (those that return just one value). If you try to use it, you’ll likely see an error.
Let’s walk through an example and the solution.
The Problem
Suppose you want to query an employee distribution table and pull in the employee’s position description from another table. You might be tempted to write something like this:
At first glance, this looks fine: grab the latest effective position for the employee. But in Athena, the ORDER BY … LIMIT 1 construct is not allowed in a subquery.
The Fix: ARRAY_AGG + ELEMENT_AT
The workaround is to use Athena’s ARRAY_AGG function with ordering, then pull out the first element of that array. This replaces LIMIT 1 safely.
Here’s the corrected version:
Why This Works
- ARRAY_AGG(… ORDER BY …) creates an ordered array of results.
- ELEMENT_AT(…, 1) extracts the first element, mimicking LIMIT 1.
- This pattern is fully supported in Athena.
Key Takeaways
- Athena doesn’t support LIMIT in scalar subqueries.
- Use ARRAY_AGG with an ORDER BY to sort values.
- Use ELEMENT_AT to extract the “first” or “top” value you need.
- This approach makes your queries both valid and efficient.
Whenever you run into Athena limitations around subqueries, look for array functions. They provide powerful alternatives to constructs that might be second nature in other SQL dialects.
