Thanks @zachary, now understand the concepts better.
I think I now know why the ownership transfer did not work (within the Particle app), it is (?) because the device was part of my company’s product fleet (am part of Dashboard beta) and my customer test account did not have a token provided by the company.
Just hanging out for @ido’s device config app now!
yes - the documentation is really useful. I have just emailed again for beta access to the Organisation beta - I need access to this to progress - any timelines on how long before access is provided?
That sounds correct @UMD. Products can only be claimed by customers of the appropriate org, not by generic Particle users. 
@Kevin Our Customer Success team has been managing the gradual rollout of the dashboard beta and gathering the feedback in rounds. @jonlogan leads that team — you two could have a private chat about which wave you’re currently in so you know what to expect.
@zachary, this is off topic, but related.
Problem with this scenario is that our organisation would like to claim the devices, not the customers. This means that we are restricted to using the Web IDE to claim. This is not a viable option in bulk (the poor Web IDE’s device’s panel fills up)… (perhaps this should be a new topic)…
Totally understandable! You should create customers for claiming them! You can even use your same email address!
Also, the organization can control the devices even if they’re not claimed if you’ve got them properly setup as products.
@zachary, it is this statement that is giving us grief:
“the organisation can control the devices even if they’re not claimed if you’ve got them properly setup as products.”
We can download firmware no worries to unclaimed devices via the Dashboard, which is a great and necessary facility. The problem is that we have no visibility of the devices connecting to our services (assume because of the API key) until it is claimed via the Web IDE.
Excuse the length of the following, but it is my documentation of what we are doing (once again, off topic):
------------- begin ----------
Out of box. Listening mode - flashing blue
Connect via serial port and enter “i” to dump the device id:
Your device id is 400029xxxxxxxxxxxx230
Next went to dashboard:
Imported a device, with the check box “Force imported devices to switch to this product” checked. In the Devices screen, Firmware version displayed as “unknown”, email “none” and “never connected” (which is all expected). When I attempted to set the firmware version with a “Lock and Flash on reset”, red message box “Error changing desired firmware version: [object Object]” was displayed. This was not expected.
Next, set up WiFi credentials in terminal - flashing cyan (i.e. downloading firmware) then - breathing blue (i.e. connected)
Next went to dashboard:
Device now Firmware version now displaying: “reporting incorrect Product ID” (expected)
Selected firmware and Locked and Flashed Now. - Flashing cyan (i.e. downloading firmware), then breathing blue (i.e. connected).
Next went to our web service.
Device did not report as being online.
Next went to Dashboard logs,
Device did not report at all.
Conclusion, device has not been claimed.
Put the device into listening mode, logged on via Particle app. Attempted to claimed Photon under my test account, the following was displayed “Oops. Setup process couldn’t claim your Photon! If the Photon LED is blinking blue or green … please contact support”
Next, whilst still in listening mode, attempted to claimed Photon under the company account, the following was displayed “Oops. Setup process couldn’t claim your Photon! If the Photon LED is blinking blue or green … please contact support”. This was unexpected.
Next tried to claim the device from the Web IDE. This worked - our service now sees the device as does the Dashboard logging service.
Conclusion: can only claim devices via the Web IDE. Devices are only visible to our web service if the device has been claimed by us via the Web IDE.
------------- end ----------
Hopefully you can see the issue… am pretty sure that I am just missing a piece or two of the process. Also sure that others may have similar issues.
Thanks - Harry @UMD
Great diagram, it really helps understand the processes! Thanks!
@UMD You are correct. The device cannot receive firmware updates until it has been claimed by either a customer or user. That’s why you were receiving those errors when trying to flash devices that had not been claimed yet.
Maybe @ido could shed some light on why the device setup on mobile was failing, but keep in mind that when you ship out your product, you will want them to be claimed by customers.
See the diagram above for the flow. Currently @ido and @nexxy are working hard on updating our SDKs to handle customer authentication. Support in the mobile SDKs should be available within the next two weeks. You are on the bleeding edge of what our platform can do 
.
I am also working on more detailed documentation of the setup/authentication process for product creators. Expect that to be released next week.
Jeff
@jeiden, yep, understood, bleeding edge! Happy to work hard with Particle to get a smooth commissioning process in place for us product makers.
Not sure that this comment is correct: “The device cannot receive firmware updates until it has been claimed” - evidence (75% sure) is that the firmware does download, and does run, but not “associated with an owner” in the cloud.
Our issues can be boiled down to this:
a) we need to test the kit before it leaves the factory, this means that it needs to be claimed
b) As we don’t know who the customers are at point (a), we, as the manufacturer, need to claim the device so that we can fully test all functionality
c) The claiming process at (b) is clunky via the Web IDE. We would like to do this via particle CLI (but there is another issue within our corporate LAN environment - we use a proxy…). I don’t think particle cli has a claim function yet. (Are there plans to do so?)
d) I see that the fundamental philosophy is for the customer to claim the device, but it is not really needed in our use cases. We just want the customer to configure their own WiFi credentials.
Hope this makes sense. I think it is all achievable. We have a work around now which is the Web IDE. Problem is what happens when is scales (we call this a “happy problem”)?
Best wishes Harry @UMD
I have the exact same use case - which seems the appropriate way to manage a fleet of devices.
So the company remains the owner - not the customer.
I believe there is some documentation bring delivered next week to more fully explain the process - hopefully this will provide more insight.
Think again 
@Moors7 Excellent!
Embarrassed to say that, of course, I should have read the doco FIRST: https://docs.particle.io/reference/cli/. Red face, whoops…
It very much looks like we are good to go on a workable commissioning process. [Only work around left now is getting the Particle CLI to work in a proxied LAN environment].
You have made my day. Thanks!
@Kevin, now that I understand that Particle CLI can be used for claiming (thanks @Moors7), it looks like you, I and others are on a good position to move forward with the “customers don’t claim” model.
No doubt philosophical debates are to be had with regard to customers claiming vs not claiming, but that can be the subject of another topic!
All good - @UMD
This is great information. Thank you Particle Team for your great work and efforts.
What we wanted to do for our devices is exactly like the Dashboard.
I was asking for how to setup the photon credentials etc without the need to use the Particle iOS and Android SDKs since we are going to be using C# (.Net) to build our platform including the mobile and web apps. We are targeting iPhone, Android, WP, Windows 8x and Windows 10 universal apps
Thank you
A webapp also offers oportunities to use this, should you be interested:
Any update on when this will be available in the Android SDK?
Waiting for exactly the same for Android, our customers are also waiting 
For whatever reason, the excellent photonsoftap.meteor.com hasn’t worked on any iOS devices I’ve tested it on. Because of this, I’ve been working on a react-native app for the past week to implement something very similar in a cross-platform manner. I’ve therefore learned quite a bit about the softap setup process and I have to say that by far, the biggest hiccup is the lack of a way to verify user-entered credentials. Is there any effort under way to improve this process both for the user and us developers? Using heuristics to determine successful/unsuccessful connection reliably and accurately while keeping the user happy and well-informed seems nigh impossible.
For comparison, the Ackme Wiconnect module provides an API call to verify the entered credentials before locking them in and attempting a connection:
http://wiconnect.ack.me/2.3/commands#network_verify
Could something like this be provided to short circuit the failure?
Hey 2 thoughts here: