IFS Permissions
Paminga reads and writes IFS through a couple of dozen projections, and your IFS administrator grants each one separately. Miss one and the integration mostly works, which is exactly what makes it hard to spot: a sync runs, then one kind of record quietly fails.
IFS Permissions takes the guesswork out of it. It asks your IFS environment, live, whether Paminga's integration user can read each projection on the setup list, and shows you the answer in a single table. Run it after your IFS admin provisions access, and again whenever something stops syncing.
Open IFS Permissions
Go to Settings > Account > Integrations, find the IFS CRM card and click Configure. IFS Permissions is in the left navigation, alongside your other IFS settings. It only appears for IFS.
The check runs as soon as the page opens. It talks to IFS in real time, so give it a few seconds.
Reading the Results
Above the table, Paminga tells you how many projections are granted out of the number checked. The table puts the rows you need to act on first: Not granted, then Could not tell, then Not in this environment, then Granted.
| Column | What it shows |
|---|---|
| Projection | The IFS projection name, exactly as your IFS admin will see it |
| Paminga uses it for | What the projection does for the integration |
| Grant | The grant level the setup guide asks for: Full or Read-Only |
| Read access | The result of the live check |
| Detail | The IFS error code and HTTP status, when there was one |
Some rows carry a note under the projection name. Optional marks a grant the integration works without. Others are noted as listed in the setup guide but not currently called by Paminga; granting them does no harm, and leaves you covered as the integration grows.
Read Access Statuses
| Status | What it means | What to do |
|---|---|---|
| Granted | Paminga's integration user can read this projection | Nothing |
| Not granted | The projection exists, but IFS refused access (SE_UNAUTHORIZED or SRV_NOT_ACCESS, HTTP 403) | Ask your IFS admin to grant it at the level in the Grant column |
| Not in this environment | IFS has no projection by that name (MI_METADATA_NOTFOUND, HTTP 404) | Usually nothing, if you don't use that part of IFS. Otherwise, check with your IFS admin |
| Could not tell | IFS answered with something other than a clear yes or no, or didn't answer in time | Click Check Again. If it persists, the Detail column has the error to pass to your IFS admin or Paminga support |
A projection that exists and is granted, but whose rows are all hidden from Paminga by row-level security, counts as Granted. The grant is what this page checks.
The check proves read access only. IFS has no way to tell a Full grant from a Read-Only one without actually writing a record, and Paminga won't write to your IFS just to find out. So a Granted row on a projection that needs Full access confirms the grant exists, but not that it's high enough. If Paminga can read a projection but fails to create records through it, have your IFS admin raise that grant to Full.
Check Again
Click Check Again after your IFS admin changes a grant. The table stays on screen while the new check runs, and updates when it finishes. Nothing is cached: every check asks IFS afresh.
To be polite to your IFS environment, Paminga limits how often the check can run. If you click repeatedly, wait a minute and try again.
What the Check Does to Your IFS
Nothing you'd notice. For each projection, Paminga asks IFS for at most one record and discards it. The check never writes to IFS, and Paminga doesn't store the results.
It uses the same credentials as your integration, so it sees exactly what your syncs see.
Fixing Access Problems
Grants are set on the permission set your IFS admin created for the Paminga integration user. IFS CRM Integration Setup lists every projection with its required grant, and explains how to track down a dependency projection IFS is blocking behind the scenes.
