Error fixIFS CloudAdministration / Background Jobs and Batch Queues

IFS Cloud Background Job Stuck in Posted or Executing

Error

IFS Cloud background job stuck in Posted or Executing

Also searched as

IFS background job not running batch queue
IFS Applications background job error how to restart
IFS Cloud scheduled task not executing
IFS batch queue processor not picking up jobs

Short answer

A background job that stays Posted is waiting for a batch queue processor that is not picking it up, while one that stays Executing is either genuinely long-running or orphaned after a crash or restart. Check the Background Jobs page for the job state and error text, confirm the batch queue is active with capacity, then requeue or cancel the job.

Applies to: IFS Cloud and IFS Applications 10; the Background Jobs and Batch Queues pages exist in both, with different navigation and client styles

How to diagnose a stuck background job

1Open the Background Jobs page and filter by the job description or the user who posted it. Note its state, queue and posted time.
2Open the job detail and read the error text and the call stack if present. Many jobs that look stuck have actually failed.
3Open Batch Queues and confirm the queue the job belongs to is active, and that it has at least one processor or execution slot.
4Check whether other jobs on the same queue are Executing. One long job can block a single-slot queue and leave the rest Posted.
5If the job is orphaned after a restart, cancel it, then post it again, rather than repeatedly editing its state.
6For recurring work, open the schedule that posts it and confirm the schedule is active and not creating duplicates.
7Raise concurrency or move heavy jobs to a dedicated queue if they regularly starve small ones.

Posted versus Executing: different problems

A job is Posted when it has been queued but no processor has started it. The usual causes are an inactive or misconfigured batch queue, a queue with no free execution slots because a long job holds them, or an application server whose batch processing is not running after an upgrade or restart.

A job is Executing while a database session runs it. If the session has died, for example after a node restart, the row can remain Executing with nothing behind it. Compare the job start time with how long it normally takes, and check whether a database session for it still exists before assuming it is slow.

Reading the failure instead of guessing

IFS background jobs run PL/SQL methods, and when they raise an error the message is stored against the job. Typical failures are business-rule errors from the logical unit (a missing period, a locked record), Oracle errors such as a resource busy condition from contention with online users, and permission problems because the job runs as the posting user.

That last point is easy to miss. A job posted by a user whose permissions were later removed, or who has left the company and been disabled, can start failing without any code change. Identify the posting user and verify they are still valid.

Queues, schedules and concurrency

Queues give you control over parallelism. Putting a nightly financial posting and a frequent small inventory job on the same single-slot queue guarantees the small job waits. Create separate queues for different workload classes and size them to the database, not to optimism.

Schedules post jobs at intervals. If a run takes longer than the interval, you can accumulate Posted copies of the same job. Look for the same description appearing many times, and consider adding logic or intervals that prevent overlap.

Safe recovery and what not to do

Prefer the supported actions in the Background Jobs page: cancel, then post again or requeue. Directly updating the underlying job tables to flip a state can leave the processor and the table disagreeing, and on managed cloud environments you may not have that access anyway.

Before rerunning, ask whether the job is idempotent. A half-finished posting job rerun blindly can duplicate transactions. For financial and inventory jobs, check what the first run already committed, then decide whether to rerun, partially rerun, or correct manually.

-- Read-only check of long-running sessions (needs DBA-level access, run by the person who owns the database)
SELECT sid, serial#, username, status, last_call_et
FROM   v$session
WHERE  username IS NOT NULL
ORDER  BY last_call_et DESC;

Common pitfalls

!Re-posting a job repeatedly while the original is still Executing, creating duplicate runs.
!Assuming Executing means progress without checking whether a database session still exists.
!Putting heavy and light jobs on one single-slot queue.
!Ignoring that the job runs with the posting user's permissions, then wondering why it fails after a user is disabled.
!Editing job tables directly to change state instead of using cancel and requeue.
!Rerunning non-idempotent financial or inventory jobs without checking what was already committed.

How an ERP-grounded AI assistant handles this

An assistant grounded in the IFS database and job metadata can answer the question people actually ask: which jobs are stuck, on which queue, posted by whom, and what error text the failed ones carry. ERPray can run that as a read-only query, show the SQL it used, and summarise patterns such as many Posted copies from one schedule. It does not cancel or requeue anything on its own; those actions stay with an administrator or go through human approval.

See ERPray

Frequently asked questions

What is the difference between Posted and Executing in IFS?

Posted means the job is queued and waiting for a batch queue processor. Executing means a processor has started it and a database session is, or should be, running it. A Posted job points at queue capacity or configuration; a long Executing job points at slow work or an orphaned session.

Is it safe to cancel an Executing background job?

Usually, through the supported cancel action, but check what the job has already committed first. Cancelling a long posting job mid-way can leave partial data. For finance and inventory jobs, review the results of the partial run before posting it again.

Why did a job that worked yesterday start failing?

Common causes are a changed or disabled posting user, a permission set change, locked records from online users, a closed accounting period, or data that now violates a business rule. Read the stored error text on the job, which usually names the logical unit and the rule.

How do I stop a schedule creating overlapping jobs?

Review the schedule interval against actual run time, place the job on a dedicated queue with limited slots, and, if needed, add a guard so a new run exits when the previous one is still active. Cleaning up duplicates alone will not fix the cause.

How-to

How to Set Up Business Events and Actions in IFS

IFS Business Events fire when a defined condition on a Logical Unit is met, such as a new record, an update, or a specific attribute changing, and Actions subscribe to those events to send email, invoke a workflow, or call an external service. Both are configured in Solution Manager (or the Events and Actions work area in IFS Cloud) without requiring custom PL/SQL for most standard cases.

Error fix

IFS Cloud OData Projection API: Fixing 401 and 403 Errors

IFS Cloud exposes its data through OData v4 projections under /main/ifsapplications/projection/v1/, secured by OAuth2 tokens from IFS IAM. A 401 almost always means the token is missing, expired or issued by the wrong realm; a 403 means the identity is authenticated but its permission sets do not grant that projection or its entity actions.

How-to

How to Add a Custom Field to an IFS Cloud Page

In IFS Cloud you add a custom field by opening the page in configuration mode, choosing to add a field, defining its name, type and placement, and publishing the configuration. The field is stored by the platform as configuration, not as a code change, which is why it normally survives upgrades.

How-to

How to Create a Generic Inquiry in Acumatica

Generic Inquiries (GI) are Acumatica's no-code query builder for joining tables, adding filters, and exposing the result as an inquiry screen, dashboard data source, or API endpoint. Open System > Customization > Generic Inquiry, add your base table, define joins and conditions, then run and save. No SQL or customization project is required.

Error fix

Fix Odoo AccessError: You Are Not Allowed to Access Records

Odoo raises AccessError when a user's security groups do not grant a CRUD right on a model through ir.model.access.csv, or when an ir.rule record rule filters the specific record out for that user or company. Fix it by adding the user to the group named in the error, editing the model's access rights, or reviewing the record rule's domain under Settings > Technical > Security.

How-to

How to Void a Check in Sage 100

Sage 100 voids checks through Accounts Payable > Main > Check and Payment Voiding. Select the bank code, choose the check number, and Sage reverses the Cash Disbursements Journal entry and reopens the invoice it paid. A check that already cleared in Bank Reconciliation or falls in a closed period needs an extra step before it can be voided cleanly.

AI for ERP