Wim Decorte

Careful with that, a text field behaves differently than a number field. If your users (or your scripts) are using that field for searches then searching for 1 will also yield 10, 11, 100,... And sorting will behave differently too. So if you were relying on that field acting as a number then you are better off leaving it as a number and using a 'shadow' filed as I mentioned.

I don't like to do this but the easiest is to add a calculated field of type text that just does "= <your number field>"

Yes, it is expected behavior. Under the hood, FM tracks most things by ID and not by name, So when you paste code (fields, scripts,...) and it has references to other objects then FM will match them up by ID, which may or may not be the field or script you intended.

Ad Manager is an odd duck in the Google realm because it's APIs use SOAP and not REST, which makes it somewhat more difficult to do from inside FM. Tougher in the sense that there are no native XML building and XML parsing functions so you have to rely on custom functions which may or may not be slow for your purpose. https://developers.google.com/ad-manager/api/start If I had to set it up for a project right now I would build a middleware web service that uses the client libraries for your preferred environment (mine would be Python or .NET) and make that web service a REST one for the FM side interaction.

I hear ya. Integrating with anything comes at a cost. You can either build or buy. If you build, you bear the responsibility of keeping track of the FedEx changes, make sure you get early notifications and spend some time on those. If you buy you have to do vendor risk management: is the vendor quick to support, are in for the long haul... decisions, decisions...

Your best bet is to use the FedEx APIs instead of xDBC. Their APIs are great and extensive, and FM happens to be really good at consuming APIs.

We would need to know a lot more about what you are trying to do and for how many records at once to know whether it would be faster to do manually. It certainly would be less tedious to do it in a scripted fashion. Don't shy away from using scripting, if you haven't used it much it will elevate your solution to the next level. And we're here to help you get there.

You don't need to view the group claims to make the authentication works. FMS receives the JWT token, decodes it and checks the groups in the groups claim against the name of the accounts (group based) that exist in the file. At the first match it assigns the priv set for that account. All of this happens in the background automatically. If you need the list of groups for a user for some other reason then yes: you'll need to use the Graph API to ask for them.

The 2empower Dev Assistant plugin can do the variable renaming for sure. Perhaps the MBS plugin can too. Not sure about layouts.

I agree, there is zero gain in waiting. In fact - depending on your OS of choice - FM requires specific OSes and that is only becoming more restrictive with FM only running on newer OSes. Delaying the upgrade may also mean being forced to upgrade OSes and potentially hardware (especially on the macOS side) if you are currently running that FM11 on old systems.

You cannot move data with a calculation. You'll need a script for that to use the Set Field script step. Can you expand on what exactly you are trying to do and how you tried so far?

@OlgerDiekstra's explanation takes care of your original request and should be easy enough to put together. However this mention from you is a totally different ballgame: I want all the summary sum of each record per account. but it shows the summary field of the entire record of the table. We don't have enough context or explanation to know what you want to achieve with that and it doesn't seem to fit with the original question of how to grab a value to display in a new card window.

Then create new groups, AD supports group-in-group memberships. It is not uncommon to create groups specific to an application or service.

You can't set a summary field, summary fields calculate their value based on the current found set. That's just how they work. If you want to show the summary of each record you'll need to sort the found set and us a subsummary layout part. Or you'll have to use a regular field and find a way to calculate the desired value yourself.

For best results, use Group-based OAuth authentication. That way you never have to add users through scripting in FM, the invites and membership are handled on the Azure AD side only. As to why it is not possible: you cannot add on-prem AD or OD or local groups or individual users either, the whole point of using External Authentication is that you have to NO account management in FM at all.