REST Query by Custom Attribute

#1

Hi all,

I’m attempting a REST query of an account but I want the query to return based on custom attribute. We are using a custom attribute to store the ID of our parent system, and when the user logs into our parent CRM system, we want to look at Dundas and if the user exists in the parent CRM, to log them in automatically to Dundas. I can successfully use:

https://myserver.com/API/account/query/?sessionId=0d0d0174-bf5a-4175-bfae-30d5530836b5

to get people by name, email and other fields…but have not succeeded in finding a way to use a custom attribute in the search. Any ideas?

Thank you!
Buck

#2

Hi @buck,

As far as i’m aware, there is no API to directly query custom attributes like you are asking. You’d have to query each account and then request the custom attributes as a second query. The problem with an approach like this is that it’s got an expensive run time and i’m concerned you’d run into performance issues.

Can you store this information in a different place for querying? Or maybe do all this querying but save the results so you that you don’t have to do it all the time? We could also enter a feature request for an API to help you but i fear you’d be one of the few people asking for such a thing.

#3

The issue I’m trying to solve is an auto-login feature from my existing CRM system. When they login to my current CRM, I want to query Dundas to see if the account exists there and if not, to create it on the fly. The only way I can know if it exists is by using an authoritative source ID from our system that is stored in Dundas and so far, the Custom Attributes fields are all I have found that let me do that. Since the users can change their usernames as will on our existing CRM, we cannot consistently use the username field as the key. How would you do it if you were in my shoes? I have an ID that never changes…no matter what they call their selves…so I’d love to save that ID in Dundas and then search for it to see if the user exists. Any thoughts are welcomed.

Buck

#4

Hi Buck,

Since you’re logging users into Dundas BI, i assume they are never going to need a login screen. Why not set their user ID as a unique identifier (GUID?) as you must have something in your system to differentiate users. You can always set the ‘friendly display name’ which is the name that users would see in Dundas BI. This way, you don’t have to worry about custom attributes and querying a user list would be easier.

#5

Yes. I thought about that…and that process would take care of the CRM-Only population for sure. The downside is that I will have two accounts for my named users: one named user login for native Dundas UI and one ID’d login for the same user when they are interacting through the CRM. I have about 120 named users who may or may not be logged in to Dundas before they hit the CRM. If they login to Dundas natively before using the CRM, I don’t want them re-authenticating with Dundas and if they login to the CRM first and then go native, I don’t want them logging in again natively. I’m also hoping not to have two logins for the same individual. For the non-native Dundas users, that would work fine…but not for the native + CRM users.

I have the following login scenarios: native Dundas, CRM, anonymous. Native Dundas must have access to the Dundas UI + the CRM; CRM only needs CRM; anonymous will only see public views made available to everyone. Further, we have windows, mac and mobile users of different devices, making single-sign on a challenge. Finally, I have to have row-level security for all users.

I’m glad I’m on the right track so far. Any further thoughts?

Buck

#6

Hi Buck,

I’m not sure there is an easy solution as you simply have a lot of things going on. I think for your CRM users, you 100% need to manage using a user name that is a unique ID as i suggested. The problem is these local users who also use the CRM. With these people you certainly don’t want to confuse them with two accounts. Since the number of these named users is only 120, could you keep a record of them somewhere in the CRM? Maybe an accounts table? This way you can look them up programatically before auto-generating them an account?

#7

You’ve been a great source for brain-storming. I’ll think out of the box and figure it out…thank you for your ideas…I appreciate your time.

1 Like