I have a salesforce site with doamin as below :
http://loram-ipsum.na15.force.com
and after almost 2 year salesforce change without any notification as below so all my resource stop working b'coz of path.
http://loram-ipsum.na46.force.com
As per my knowledge "na15" stands for server location (north america 15).
Thanks.
In order to prevent this from happening in the future, consider implementing 'My Domain' (https://help.salesforce.com/articleView?id=domain_name_overview.htm&type=0). This will allow you to have a specific domain without the specific server identifier in the address.
Related
As you know Salesforce is enforcing Enhanced Domains. I found from Salesforce help that:
Custom components in your org must be evaluated in order to check
whether they use domain name/static URLs
Some embedded content stored in Salesforce might no longer appear
Third-party applications can lose access to your data
Single sign-on integrations can fail
However, I'm struggling with finding out which particular Salesforce elements/configurations should be checked in order to detect potential gaps? Do you know which areas exactly can be affected and shall be evaluated (like Apex Codes, Email Templates and so on)? Is there any guide on that?
Your biggest concern should be inbound integrations. Things that log in over REST/SOAP API, get response with session id back, ignore the "url to use for all subsequent requests" and just use hardcoded url, whether it's prod or sandbox.
Look at this guy, he's victim of either enhanced domain or "disable api versions < 30" thing: The requested resource no longer exists with rest PHP. Look at these guys, they had hardcoded url: how to solve python code error (TooManyRedirects: Exceeded 30 redirects), Salesforce API via postman error INVALID_SESSION_ID.
As for stuff inside Salesforce itself - best would be to download whole project with sfdx and run a text search for your domain name (and site/community name if you have these). Email templates that use merge fields for forgot password etc should be fine, merge fields with record link should be fine... But if you manually craft email body in apex - might be a problem. A lot depends how creative the developer was. If you find getsalesforcebaseurl().toexternalform() it should still work. If it's hardcoded / read from custom setting / custom label / custom metadata it might be more fun.
If you have external apps that display pieces of salesforce (embedded live chat? some iframe with FAQ? CMS Connect) - the domain change might mean they need to be updated, both in terms of updating url and changing security rules (CSP for example)
While looking at our snowflake.account_usage.login_history in order to identify users with outdated client drivers (using reported_client_type + reported_client_version), I came across this user_name that I did not recognize: WORKSHEETS_APP_USER.
It's not one of our users, so I'm wondering where it's coming from.
The client driver it's using is OTHER 1.1.5.
It's using OAUTH_ACCESS_TOKEN to authenticate (which is not an authentication method we use for Snowflake).
And it's using a ton of different IPs in the 10.4.* range.
It has a lot more logins during the week than during the weekend -- so probably a human(s).
I'm thinking it's probably related to the worksheets UI (either in Snowsight or in the old console).
If so, would there be any way to know who was the original user(s) behind this activity?
The first time Snowsight is accessed in an account, Snowflake creates an internal WORKSHEETS_APP_USER user to support the web interface. This user is used to cache query results in an internal stage in your account. For more information, see Getting Started With Snowsight.
https://docs.snowflake.com/en/sql-reference/account-usage/users.html#usage-notes
Salesforce has notified us that our org will be migrating from one instance to another in January. With regards to our Docusign integration, will this interrupt access or affect the Docusign integration otherwise?
We use mydomain, so while our hard coded org ID will change, our org url will not. Hopefully this results in no change in our integration, but I want to be sure and prepare for the change if I can.
You need to complete the steps in here and you should be fine.
https://support.docusign.com/en/guides/apps-launcher-troubleshooting-page
https://support.docusign.com/en/guides/dfs-troubleshooting-page
We cannot support you over stackoverflow, but it's possible to update domain and orgIDs in salesforce if you follow the instructions. If you still get stuck - you'll need to contact customer support.
I work in a big company and we have just migrated to office 365 in a hybrid scenario.
Here is the "stack":
Exchange 2016 Hybrid
ADSync with AADConnect
Usermailboxes hosted on Office 365
Users use the Outlook 2016 Client (can't roll out o365 client, because we have over 50.000 users and so many custom outlook plugins 32 Bit)
We do this as followed:
Create a new ad user.
Enable-RemoteMailbox samAccountName -RemoteRoutingAddress samAccountName#tenant.mail.onmicrosoft.com -PrimarySmtpAddress address#tenant.com -shared
(This also turns of emailAddressPolicy which it should do according to our exchange admins). Our exchange admins are also stuck on that problem so that's why I created this post here)
Then I wait and have a look in the ECP Admin center. Before the sync happens the remote Routing address is: address#tenant.com
After the first sync (every 30 minutes) it's samAccountName#tenant.mail.onmicrosoft.com ==> How it should be.
After another 30 minutes (2nd sync back to AD) it's a X500 address.
When I look it up in PS like get-remotemailbox <UPN> | fl *remote* the address is samAccountName#tenant.mail.onmicrosoft.com (how it should be).
So it's displayed wrong in the ecp.
But the huge problem we face is this:
When I give any user from the company full access to this shared mailbox it won't get Automapped.
After 1 hour of waiting I manually add it. When I do this a .OST error comes.
Error:
"Microsoft Outlook cannot expand the folder. The set of folders cannot
be opened. The file
C:\Users\UserName\AppData\Local\Microsoft\Outlook{username]}.ost"
Also with outlook restart it's not working. So our guess is because something is wrong about ECP and the Remote Routing address.
Please note that this isn't a client problem. It effects almost every mailbox I create these days.
I had another post about this but with fewer details and without the knowledge of the remote routing address: https://www.reddit.com/r/exchangeserver/comments/eceqm6/automapping_doesnt_work_on_hybrid_setting/
Anyone have any ideas? I appreciate any kind of help from you guys. If you need any more informations please ask
You have an Hybrid architecture, ok. You need to use O365, because if you use older versions you will need to change a bit the computer registry in each computer. Or change the on-premise autodiscover.
But your big problem is big indeed. Right now, you can not hare mailboxes in O365 correctly. If you do that, you may have access to main mailbox, but if you use archive, you won't have access (you just have OWA access).
Regards.
We now have one site running but we will need to build a branded site for our client soon. The client site will have exactly the same data set as our current site expect for the user data. The client site must have totally separated user info which allows only the client to use the site.
I don't see the need for setting up a new database or creating a new user table for the client. My tentative solution is add a "Company" column for the user table so that I can differ which site the user data row is on.
I do not know if this approach will work or not or if it is the best practice. Could anyone with experience like this shed some light on this question?
Thanks,
Nigong
P.S. I use LAMP with AWS.
Using an extra column to store a company / entity id is a common approach for multitenant system. In general you will want to abstract the part that that verifies you can only retrieve data you're allowed to a piece that all queries go through, like your ORM. This will prevent people new to the project from exposing/using data that shouldn't be exposed/used.