Ishaan.
I think there are three areas worth reviewing here...
#1 Login ID.
The relationship to what can be seen is that you have a user account defined in SAP and associated with a particular employee in Infotype 0105 (as described by Stephen Burr). The user account should have a SAP profile associated with it that you then map to the corresponding Nakisa profile (the step after setting the Employee Source - as shown in your screen shot.
So this relates user account to employee and user account (via SAP profile) to the Nakisa role.
#2 cds.log.
You say there are no errors in your log, and whilst I agree all the lines are marked INFO, lines 4 and 6 suggest that all is not in fact error free.
Line 6 states "Login process finished with errors".
More interestingly, line 4 says "User to authenticate is null". So that looks to me like the user ID you think is being passed into Nakisa isn't. The best way to confirm this is probably by accessing the Nakisa debug page.
To do this, login to OrgChart with your "suspect" account. Now open a new browser tab/window, copy & paste the URL of OrgChart into the new tab and modify it to access the page /nak-debug.jsp.
For example if your OrgChart URL was:
you would change this to:
This will provide you with lots of additional information about what data is being passed to Nakisa and specifically more about who it "thinks" you are and what org unit it thinks you belong to.
See the "Debugging User and Session Information" page on the VSN wiki for further details. After reviewing it if you still have issues with what it means it may be worth posting a screen shot to this thread.
#3 Hierarchy root/security
When configuring hierarchies you can specify what root the hierarchy should start from (see root hierarchies in the Admin Guide) - a universal static root or one based on the user record for the logged in user.
Access to certain features (e.g. analytics) for specific Nakisa roles could be enabled (e.g. analytics for HR role), disabled (e.g. analytics for everyone role) or enabled for own org unit and below (hierarchy scope - e.g. analytics for manager role).
These two configuration aspects (root node and permissions) are independent of one another - enabling/disabling/modifying one will not directly affect the other.
Hopefully that should now give you some pointers to figure out who OrgChart thinks you are logging in as, what role you are being mapped to (and how to map it if you aren't doing so already) and how to specify a dynamic (user based) hierarchy root (if that's what you are after).
Regards,
Stephen.