Community Spring Cleaning week is here! Join your fellow Maveryx in digging through your old posts and marking comments on them as solved. Learn more here!
The Product Idea boards have gotten an update to better integrate them within our Product team's idea cycle! However this update does have a few unique behaviors, if you have any questions about them check out our FAQ.

Alteryx Connect Ideas

Share your Connect product ideas - we're listening!
Submitting an Idea?

Be sure to review our Idea Submission Guidelines for more information!

Submission Guidelines

Alteryx Connect : The function to import the user list.

Our client is considering introducing Alteryx Connect.


They are considering sharing metadata to thousands of users.
So it is not realistic for administrators to create accounts one by one.
Therefore, we want the function to import user lists.


Initially we considered connection with AD,
However, we could not be used because users and server of Alteryx Connect belong to different domains.


Therefore, we want the ability to import user lists.
Or, we want an extension to import account information in AD into Alteryx Connect.

7 Comments
VojtechT
Alteryx
Alteryx
Status changed to: Comments Requested

Hi @Hiroyoshi ,

 

when you say "different domains" do you actually mean different subdomain like "europe.company.com" and "america.company.com" or really different ones like "companyA.com" and "companyB.com"? because Connect can handle the subdomains as long as is part of one itself. But if there are two completely different domains, then yes, that doesn't seem feasible. 

 

People folder allows XLS export, but not XLS import. What it does support though is XML export and import. I tried to export users from one instance and import them into another and it seems to be working. So "the only" thing you need is to find a way how to export your users into xml of desired structure. 

 

The AD loader is on our roadmap for Q4 this year (but I believe we make it to have it earlier) and I guess that should solve your issues. But in such case Connect will still need to have visibility to all AD servers - that means they need to be on the same network. And so I would ask why the WinAuth isn't working in first place. The users don't have to be all in the same domain. They only need to have different email addresses. 

Hiroyoshi
6 - Meteoroid

Thank you for your reply.

 

> when you say "different domains" do you actually mean different subdomain
> like "europe.company.com" and "america.company.com"
> or really different ones like "companyA.com" and "companyB.com"?
> because Connect can handle the subdomains as long as is part of one itself.
> But if there are two completely different domains,
> then yes, that doesn't seem feasible.

 

In this case, "different domains" that we said are really different like "companyA.com" and "companyB.com"

 

> People folder allows XLS export, but not XLS import.
> What it does support though is XML export and import.
> I tried to export users from one instance and import them into another
> and it seems to be working.
> So "the only" thing you need is to find a way how to export your users into xml of desired structure.

 

OK, we understand.

 

> The AD loader is on our roadmap for Q4 this year
> (but I believe we make it to have it earlier)
> and I guess that should solve your issues.
> But in such case Connect will still need to have visibility to all AD servers - that means they need to be on the same network.
> And so I would ask why the WinAuth isn't working in first place.
> The users don't have to be all in the same domain.
> They only need to have different email addresses.

 

We have questions about AD Roader.

What is the role of "AD Roader"?
We think/assume AD Roader takes up users information from Active Directory, and AD Roader imports it to Alteryx Connect.
Are our thinking/assumption correct?

VojtechT
Alteryx
Alteryx

Hi @Hiroyoshi,

 

yes, you are correct. AD Loader is a job that connects to the AD server and based on the configuration like starting point and filters it extracts all relevant users and groups and creates their counter-part in Connect. Of course it is not able to extract their password, so the users have to create their own first using the "Forgotten password feature" (working SMTP required). 

 

But one thing is not clear to me - AD servers are usually accessible only from the internal network, so I am not sure if even this loader would work in your case anyway if your users are in two different domains. The Connect server will need to be able to connect to both AD servers, so I would advise to validate this condition. 

Hiroyoshi
6 - Meteoroid

@VojtechT 

 

I understood.

However, it is not practical to manage passwords separately when using the "AD loader".

In the method of importing user information using XML, is it possible to import also password?

VojtechT
Alteryx
Alteryx

@Hiroyoshi ,

 

in that case what you are looking for is an external "vault" that would Connect utilise. I'm afraid that is not we would plan for Connect in this or next year. 

 

If you want to avoid any password management in Connect, you already have two options:

  1. to use the Windows authentication - in such case, the password in Connect doesn't exist as the AD is doing all the authentication
  2. to use the SAML authentication method - in such case, a 3rd party is taking over the authentication and Connect doesn't store any password as well. 

Since you have two different domains, the 1st case cannot be utilised. (Or maybe if the domains would have trust established between them, then it could work as long as Connect is at least in one of those domains).

 

In the second case - I know the SAML providers are usually able to connect to your AD, so if they would be able to connect to two ADs, it could merge all users from both ADs and users could authenticate via that SAML provider. 

 

 

Hiroyoshi
6 - Meteoroid

@VojtechT 
OK, I understood.

I will ask you If I have another question.

Thank you!

VojtechT
Alteryx
Alteryx
Status changed to: Not Planned

Hi, I'm moving this idea into the Not Planned stage, since Connect already provides several options of utilising externally managed users and we do not plan to add another way.