Resolving the SU_UNAUTHORIZED Error in IFS Migration Excel Add-In

Introduction

The IFS Migration Excel Add-In is a powerful tool for data migration projects within the IFS ecosystem. It allows consultants and administrators to efficiently extract, transform, and load data directly from Excel into IFS, making migration jobs faster, more transparent, and far easier to manage. For migration projects — whether they involve setting up a new system, upgrading, or consolidating data — this add-in is often an essential part of the toolkit.

But as with any powerful tool, success depends on more than just knowing how to use it. Migration projects inevitably involve complex configurations, multiple systems, and security settings that must align perfectly. That’s why understanding the errors you encounter — and knowing how to resolve them — is critical.

One such error that can halt progress is SU_UNAUTHORIZED. This error is a signal that there’s a permissions or authorization issue preventing the add-in from completing its task. Left unresolved, it can stall migration work, cause delays, and increase project risk. On the other hand, addressing it efficiently requires understanding both what the error means and where it originates.

fig1: SE_UNAUTHORIZED user error

In this post, we’ll explore the SU_UNAUTHORIZED error in detail, break down why it happens, and walk you through a practical approach to resolving it so your migration jobs can proceed smoothly and securely.

Understanding the SU_UNAUTHORIZED Error

The SU_UNAUTHORIZED error is one of the more common stumbling blocks when working with the IFS Migration Excel Add-In. At its core, this error means the add-in is trying to perform an action for which the current user does not have sufficient permissions. But the causes can vary, and understanding them is key to resolving the issue effectively.

Here are a few common scenarios where the SU_UNAUTHORIZED error might occur:

• Attempting to access or modify restricted objects — For example, trying to migrate data into a protected table or module without having the necessary rights.

• Using an account without required migration permissions — Even if a user can log in to IFS normally, migration operations require specific permissions that aren’t granted by default.

• Changes in security roles or direct grants — If a user previously had permission but roles were modified or removed, the add-in may fail with this error.

• Incorrect or incomplete configuration of the migration job — Permissions for migration aren’t automatically created when you build the job; they must be explicitly granted to the executing user or role.

It’s important to note that creating a migration job does not automatically grant the necessary permissions to run it. Permissions in IFS are controlled separately and require careful configuration. The migration job defines what data needs to be moved and how, but it doesn’t alter security settings. That means unless the executing user already has the correct rights, the job will fail — often producing the SU_UNAUTHORIZED error.

Understanding this distinction is critical. It shifts the focus from assuming a migration job “should just work” to recognizing that permission configuration is a deliberate and essential part of preparing a migration. Without addressing it, even the most meticulously planned migration job can grind to a halt.

The Role of Projections in Migration Jobs

In the context of IFS Migration Jobs, a projection is essentially a way of defining how data is mapped and transformed during a migration process.

A projection acts as a blueprint for the migration job, specifying:

• Which data fields or columns are being migrated.

• How the source data (from Excel, CSV, or another system) corresponds to the target structure in IFS.

• Any transformations or rules that need to be applied to the data during migration — for example, converting formats, applying default values, or combining fields.

Think of it like a view or translation layer: the projection “projects” the data from its current form into the format IFS needs, so the migration job can import it accurately.

In practical terms:

• In the IFS Migration Excel Add-In, projections are defined for each migration job and determine how the data you work with in Excel will be processed and inserted into IFS.

• They also control which permissions are required, because migrating data according to a projection often involves interacting with specific tables, forms, or APIs in IFS.

For example: If you are migrating supplier data, a projection might define that your Excel column “Supplier Name” maps to the SUPPLIER_NAME field in IFS, and “Supplier ID” maps to SUPPLIER_ID. If certain validations or transformations are needed (e.g., trimming spaces or converting date formats), those rules are included in the projection.

This is why projections are critical: they ensure the migration job knows exactly what to do with the data, and they also influence the permissions needed — which ties directly back to errors like SU_UNAUTHORIZED when permissions for a projection aren’t correctly configured.

Permissions and User Roles

Think of it this way: the migration job is the “task” and the projection is the “blueprint.” Even if the user is authorized to run the task, they must also have permission to read and use the blueprint. Without that permission, the system treats it as an unauthorized operation.

This is why part of preparing a migration job includes verifying that:

1. The projection exists and is correctly configured.

2. The executing user (or their role) has the necessary rights to the projection.

One of the less obvious — and often frustrating — aspects of IFS Migration Jobs is that creating a job does not automatically grant the creator access to the projection used in that job. This can easily cause confusion, especially for those new to IFS migration projects.

It’s natural to assume that if you create a migration job, you automatically have all the rights needed to run it. But in IFS, permissions are managed separately. The job itself is one object, and the projection is another. Access to one does not imply access to the other. This separation exists for good reasons — it helps enforce security and maintain control over who can run which migrations — but it can catch users off guard.

The result is a common scenario: a migration job is created and configured perfectly, but when the creator attempts to execute it, they encounter the SU_UNAUTHORIZED error. The culprit isn’t the job itself, but missing access rights to the projection. This often leads to wasted time troubleshooting what appears to be a technical or configuration issue, when the fix is simply granting the correct permissions.

Understanding this distinction early is crucial. It not only prevents unnecessary delays but also reinforces the importance of checking both job and projection permissions before executing a migration.

Step-by-Step Guide to Resolve SU_UNAUTHORIZED Error

Identify the User Executing the Job

Is this job being executed by you? by someone else? what is the exact username for that user?

Check Permission Sets for the User

I prefer going from Permission Sets to Projections than the other way around. The way IFS forms is organized makes it easier to assign permissions this way. There is no form called "Projection" where you can see all the Permission Sets that have permission to it but the other way around (seeing a Permission Set form with all the projections this permission Set has been granted) is possible. That's why I like to approach the solution that way.

So, in order to solve this, the second step is going to the user and see the Effective Permission Sets (or a Permission Set Matrix document if have read my previous blog post and your organization has one). Select what Permission Set my user will be using to access this Projection is a matter of making appropriate use of Permission Sets and use a good naming convention where the Permission Set clearly states what is the main purpose. For example, I can have a permission set called IFS_MIG_EXCEL_ACCT for all the projections used by the Excel Add in for the Accounting department (if I choose to separate access based on that criteria). There is no right or wrong, the important thing here is consistency.

fig2: Observe the Permission Sets your user is assigned to and select a candidate for Projection granting

Grant Permission to Required Permission Set

Go to the Permission Set form for the selected permission set and navigate to the Projections section. Click to the Add/Revoke button.

fig3: Projections section on the Permission Set form. We are going to add a Projection here.

Once we click the button and select "Add", a fly-out screen will open asking you to select the Projection you want to assign to the permission set. Here we will select a permission set named after our migration job following the following rules

1. The underscores in our migration jobs are removed

2. The first letter after the underscore is capitalized

3. All the other letters are lower case

4. The suffix "MigJobHandling" is added

For example, for a migration job called TEST_PART_PLANNING, the associated Projection will be called TestPartPlanningMigjobHandling. Once we grant that Projection to the Permission Set the error should go away and you should be able to migrate your data using the Excel Add-In without problems.

Conclusion

The SU_UNAUTHORIZED error in the IFS Migration Excel Add-In is more than just a technical hiccup — it’s a sign that permission configuration needs careful attention. Understanding the relationship between migration jobs and projections, and recognizing that creating a job does not automatically grant all necessary access, are key steps toward preventing and resolving this error.

For organizations running migration projects, overlooking these permission details can mean costly delays, frustration, and a slowdown in delivering business value. Addressing them early not only ensures smoother migrations but also strengthens the overall governance of your IFS environment.

As a technical consultant specializing in IFS, I help teams navigate these complexities. From diagnosing migration errors like SU_UNAUTHORIZED to designing permission structures and optimizing migration workflows, I work with you to ensure your projects run efficiently and securely.

If you’re tackling a migration in IFS and want to avoid unexpected errors, wasted time, and security gaps, reach out to me. Together, we can solve your Excel Migration challenges, streamline your process, and set your migration up for success.

Contact me today and let’s make your IFS migration smoother, faster, and error‑free.